[gmpi] Re: NAMM follow-up, some major decisions to make

From: "Tom White" <twhite@xxxxxxxx>
To: <gmpi@xxxxxxxxxxxxx>
Date: Mon, 31 Jan 2005 15:25:04 -0800
Mike was discussing benefits of GMPI, and Tim was playing devils
advocate, and since I was at the meeting I thought I'd add some
comments, too...

> > - Lower development costs since you only need to support one
> > plugin API.
> 
> ...GMPI increases development costs.  First you pay engineers
> to add support for GMPI.  Then they maintain it.  Then a few 
> years from now they rip out the older (sub-)standards.  Where's
> the savings? 

Mike's principal (one API = lower costs) makes logical sense, but is
probably too late to be applied today... as Tim points out, everyone
is already committed to at least one, so GMPI will be more, not less.

Also, some hosts already only support one API, so GMPI can't provide
that benefit. I'm told that some plugin developers already have their
code modularized to make it relatively easy to support multiple API,
so they too don't "need" to have a single API. Not that a standard
wouldn't be easier, just that it might not be justifiable to some of
the major players at this late date. Still, things can change...

> > - No developer support required since you do not control the API.
> 
> Something in this vein was mentioned and the response was "we'd
> rather control it, thanks".

The people who are controlling their own API and being successful are
not likely to think they need to stop <g>. But others may not feel
the same way about that, and just weren't vocal at the meeting.

> > - Increased ability to create a single working environment for
> > your customers. Currently, customers may need multiple hosts in
> > order to access plugins or specific features only available on
> > particular hosts.
> 
> This is utopian.  It just doesn't sound like an achievable goal.
> (you and I know it is achievable, but it will require a concerted
> effort to get there).

Even if it were possible, it may not be really necessary at this point.

The response I hear to this complaint is that multiple environments
are not actually a problem for users because wrappers exist; major
plugin developers do not have a problem because they modularized their
code to deal with multiple hosts; and hosts don't consider this a
problem because developers and customers are supporting them. 

The one exception would be smaller developers who don't have the
expertise to support multiple APIs... everyone seemed to acknowledge
that GMPI would be a good thing to have for them (as you mentioned
later in this email).
 
> As for being well designed - are we saying that we can design a 
> better API than all these other companies?  Are we saying they have
> done a bad job? More or less, yeah.  As for being next generation,
> this means overhauling hosts.  And while hosts get overhauled (over
> a few years), GMPI plugins can't rely on any of the advanced
> functions of GMPI.  So no plugins will take full advantage of them,
> so no hosts will support them.

Actually, I don't think next-generation design ideas should be
tossed out of discussion yet. Clearly some of the MMA members who
are controlling host APIs have said that another API that does not
solve anything is not a viable option... so maybe one that solves
things is. Maybe this could be investigated further...

> I still see all the benefits of GMPI.  Especially if we have 
> even a few feet in doors.  Having you, Mike (Adobe) and Ron
> (Cakewalk) involved in this gives me hope that if we DO do GMPI,
> it won't be just so much wasted energy.

Well, it *is* a lot harder to dismiss a competing idea as invalid
in the market place when there are actually people willing to make
the investment to bring it to market...
 
> We have a huge amount of useful information in this requirements
> document.  The industry should thanks us for that, if nothing 
> else.

I think everyone has acknowledged this, including the two "bad guys" 
who have spoken up so far <g>. If not, then I will acknowledge it:
The requirements document is going to be very useful, regardless of 
what else happens with GMPI, thanks to all of you.

> We can write a whole new API and start moving to it.  Or we can
> work with the industry to sculpt current APIs.  GMPI can be a 
> whole new answer or a compatibility layer.
> 
> I'm not sure what is the right answer.  I'm still noodling on it.

I think we all feel that way at the moment. Sometimes it takes a
while of discussing and thinking to develop consensus.

Tom White
MMA

----------------------------------------------------------------------
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: //www.freelists.org/archives/gmpi
Email gmpi-request@xxxxxxxxxxxxx w/ subject "unsubscribe" to unsubscribe
References:
- [gmpi] Re: NAMM follow-up, some major decisions to make
  - From: Tim Hockin
[gmpi] Re: NAMM follow-up, some major decisions to make

Other related posts:
