[gmpi] Re: MIDI: Proposed Requirements (wrap up try #1)

--- Ron Kuper <RonKuper@xxxxxxxxxxxx> wrote:
> >>>
> Just look at Audio Units. The AU API does include an extended musical
> event API, and is anyone making use of it? Not that we have seen. This
> is because plain MIDI is also directly supported in AU. And so the nice
> work that was done to make an extended musical event API has been for
> nothing, because developers just take the shortcut of supporting only
> the
> direct MIDI stuff in AU. 
> <<<
> 
> That's too bad, but it was an avoidable mistake.  We too can avoiding
> building a grand edifice and leaving it empty.  AU has demonstrated the
> perils of trying to create something better than MIDI.  Perhaps AU
> developers chose to support MIDI because of the stated reasons by the
> MiG camp: it *is* sufficient for most real world applications; it is
> deeply established in the commercial world.  
> 
> (I know MIDI isn't what we want in the long terms.  Maybe AU's problem
> was that its event API doesn't extend MIDI as cleanly as it should?)
> 
> I see the state of non-MIDI control in AU is an argument for MIDI in
> GMPI.

Hold on, at this point, you should *not* be drawing conclusions.  As you
say yourself, you don't know about the situation with AU.  But then you
continue on to draw conclusions about it and what that means for GMPI. 
Once you acknowlege that you don't know what you're talking about, you
should either learn about what you're talking about, ask someone else who
knows, or stop talking.

I, for example, am familiar with the extended musical event API in AU.  :)
 And I would say that it is clean, it is basically the sort of thing that
we've talked about here before (using note instance IDs, any frequency
value, etc.).  Of course it's not at all difficult to make something
cleaner than MIDI...  ;)

> >>>
> Isn't one of the main purposes of GMPI
> supposed to be to learn from the lessons of all of the previous plugin
> APIs?
> <<<
> 
> No, it isn't.  The purpose of GMPI isn't to make The Best API.  The
> purpose of GMPI is simply to choose one and standardize to it.  Here
> again is the mission statement for GMPI from the day this list began:

Well, maybe it's not in your summary of the purpose, but certainly plenty
of folks were saying what I am saying early on in the process.

> The reason I approached the MMA about starting this group wasn't because
> I thought the industry needed another plugin API.  Quite the contrary,
> there are too many.  We just need one, but the trick is it needs to be
> owned by a trade association or a standards group, not a corporation.
> Today our choices are:
> - VST (Steinberg/Pinnacle)
> - DirectX (Microsoft)
> - AU (Apple)
> - RTAS/TDM (Digidesign)
> 
> I would happy call any of these GMPI 1.0, warts and all, knowing that
> the future of the API was in safe hands and that we could "fix it" in
> versions 2, 3, etc.

You might be happy, but how happy is anyone else going to be to go to the
trouble of supporting it?  This is one of the few areas where we actually
can give a solid improvement to existing APIs, giving lots of folks what
they've wanted to see for years, and giving an actual compelling reason
for GMPI to exist.  I fear that the compromise here marks the beginning of
GMPI miserable failure...

Marc


                
__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - Send 10MB messages!
http://promotions.yahoo.com/new_mail 

----------------------------------------------------------------------
Generalized Music Plugin Interface (GMPI) public discussion list
Participation in this list is contingent upon your abiding by the
following rules:  Please stay on topic.  You are responsible for your own
words.  Please respect your fellow subscribers.  Please do not
redistribute anyone else's words without their permission.

Archive: http://www.freelists.org/archives/gmpi
Email gmpi-request@xxxxxxxxxxxxx w/ subject "unsubscribe" to unsubscribe

Other related posts: