[gmpi] Re: Topic 7.1: Channel Formats

  • From: Chris Grigg <gmpi-public@xxxxxxxxxxxxxx>
  • To: gmpi@xxxxxxxxxxxxx
  • Date: Wed, 4 Jun 2003 13:54:23 -0700

what's the difference between that and "if you don't want your host to
support RTAS, then reject it", or "if you don't want your plugins to
support TDM, then reject it"?

every fork in the road of possibilities creates a (lossy) choice that
has to be made by developers and represents a potential source of
dissatisfaction for users.

This is true only to a limited extent, and disregards: larger economic benefits and market effects of standardization; technical issues of evolution over time; and how small the set of choices would be at first.

If GMPI becomes successful, GMPI support will be a part of most or all hosts.

If GMPI support is a part of most or all hosts, it will be possible for a plug publisher to reach a very large market with just GMPI API plugs.

If plug developers write to just the GMPI API, and GMPI -doesn't- use a parameterized architecture, then over the years as user/market requirements (like formats) change, the GMPI API will eventually reach a breaking point where the underlying assumptions fail, and tremendous effort will have to be spent throwing out GMPI and adapting to Yet Another Plug-in Format (YAPF). Since many developers could be using GMPI at that point, the aggregate loss is significant.

If plug developers write to just the GMPI API, and GMPI -does- use a parameterized architecture, then over the years API can be revised one area at a time as user/market requirements (like formats) change, allowing developers to focus on just the specific changes; everything else stays the same, avoiding the tremendous cost and effort of adapting to YAPF which would be otherwise be required. Aggregate savings is significant.

Going with GMPI in the first instance has time and effort costs, but a) if GMPI is designed well, these can be minimized (see previous email in re. defaults for v1.0 and not offering lots of choices initially). Looking beyond the initial costs, we have the opportunity to design GMPI in such a way as to eliminate or drastically postpone future YAPF costs, and simultaneously minimize the cost of supporting future GMPI levels. Whereas if we do not take this opportunity, GMPI will be abandoned much sooner... in which case, why start down the GMPI road?

-- Chris


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

Other related posts:

  1. Home
  2. gmpi
  3. Archive
  4. 06-2003