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

I'll play devil's advocate, because I saw this happen first hand.  Ron
did an good job of defending our position, but the attack was rather
fierce.

On Fri, Jan 28, 2005 at 10:19:47AM -0700, Mike Berry wrote:
> - Widest possible variety of 3rd party plugins available for your
> host._
> This may be of particular interest to hardware developers who rarely_
> have had access to 3rd party plugin innovation.

To get the widest variety, you'll need to support VST, AU, DX, RTAS,
*AND* GMPI.  At least for the first few years.  It won't just cut over
to all GMPI.

> - Lower development costs since you only need to support one plugin
> API.

See above.  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?  That
is a lot of money to get back to where they are more-or-less today.

> - Never having to support a plugin API controlled by a competitor.

They don't seem to care much about this.  Apple *doesn't* support
competing standards.

> - 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".

> - 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._
> In the GMPI environment, particularly with nested hosts, the user can_
> stay within their chosen host for all operations.

This is utopian.  It just doesn't sound like an acheivable goal.  (you
and I know it is acheivable, but it will require a concerted effort to
get there).

> - A chance to discard legacy baggage accumulated over a number of
> years_
> within your own proprietary API.

That baggage directly reflects features, bugfixes, and customer needs.
Total re-writes are almost always a bad idea, because you lose all those
years of accumulated details and edge-cases.

I'll add to your list:

* Plugin developers only need to write to a single, well designed, next
generation API.

And the response:

Even if GMPI *does* fly, hosts will transition to it over a period of
years.  In the mean time, plugin authors need to support all the things
they currently support and GMPI as well.  More work.  Hosts will do a
lot of work to get back to where they already are (more or less).  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.

Further, all the 'big' plugin houses already have internal APIs that
they code to, which drop into AU, VST, etc formats.  GMPI's single API
does them no good.  It's only small plugin developers that really pay
the price for supporting multiple APIs.

> >-----Please add to this list is you see other benefits to companies
> >with_
> established hosts and/or plugin APIs.

Add another item:

* We can fold in support for other OSes and applications that currently
get left out.

Response: You mean Linux.  Linux people don't spend money, so why should
we care?



Now, I'm still processing all that happened last weekend, so I am just
kind of rambling.

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.

I also see a need for a next generation API.  AU is good, and does some
of what GMPI specs.  If Apple gave us AU, I could see having AU on
Linux.  The API sucks from a style point of view, but I think all
Apples's coding conventions kind of suck (my opinion).  But I could get
on with my life.  Ditto VST.

I also see a HUGE need for something on Linux.  LADSPA is good, but
doesn't go far enough. DSSI is intended to be temporary, though it could
get enough traction to stick forever.

We are at a point where we can decide to be evolutionary and try to
rally industry support a priori, or we can be revolutionary and hope
that we become such a disruptive force that we change the industry along
the way.

We have a huge amount of useful information in this requirements
document.  The industry should thanks us for that, if nothing else.  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.

One idea put forth at NAMM was to make GMPI an abstraction layer.  Write
your plugin to GMPI, then link it with a VST face or an AU face or
whatever.  What you get is a simpler way to write your DSP, but your
final build is a plugin in VST or whatever format.  This would be a huge
boon for small developers, though may not be very realistic.

I'm not sure what is the right answer.  I'm still noodling on it.

Tim


----------------------------------------------------------------------
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: