[gmpi] Re: where we at
- From: Paul Davis <paul@xxxxxxxxxxxxxxxxxxxxx>
- To: gmpi@xxxxxxxxxxxxx
- Date: Mon, 04 Aug 2003 21:42:31 -0400
>I like Michael's proposal. We spend a lot of effort arguing about
>implementation details, and a lot of time arguing about which of two
>approaches is simpler/more efficient/etc.
> If we had an *absolute* minimum implementation. It would provide a test
>bed for various ideas.
we have an absolute minimum in the form of LADSPA already. those of
us from the linux world are very familiar with both its strengths
(extreme simplicity), and its weaknesses (to many to mention).
> I don't know how many times I've dreamt up a simple, elegant design, only
>to have it crash and burn under the harsh reality of actually coding it.
i tried to explain my view of this aspect of the design before.
it is *perfectly possible* that the outcome of the GMPI "process" will
be to simply adopt CoreAudio (or VST or DirectX or whatever). but its
not sensible to try to jump to such a design before first outlining
what it is that **we** want from the API. apple believes that they
have covered all the bases when they designed CoreAudio, yet from the
discussions i've seen, they consulted with very few people outside
their own group. the same thing has happened with VST and the rest. we
have already raised and discussed issues that show little sign of
having part of the design process for existing proprietary APIs. we
have talked about multiple processors (including a discussion of those
lacking FPU capabilities), multi-platform issues, issues of
efficiency at a very, very fundamental level, and so on and so forth.
i personally tend to concur with marc that its likely that CoreAudio
is exceptionally close to what we will find we want (following a
global renaming of the entire API :). but until we have defined all
the parameters that were outlined by ron at the outset, its simply
impossible to determine that.
>I suggest it's also a more modern, iterative approach to design. ("Extreme
>Programming" is the label).
>Our current approach is more 'top-down'?, is that the term?. (the word
>"Bloatware" also springs to mind, but perhaps i'm biased).
there is a deeper problem here. extreme programming works very well
for teams. there is no team here. we have interest from
employees/owners of many different audio software companies, and our
goal is something that we can all adopt. this is an entirely different
s/w engineering problem than the one XP is designed to tackle.
tim and others on the LAD list got a long way in their efforts to
forge ahead with XAP, which was an attempt to learn directly from all
the existing APIs that were reasonable openly documented. that effort
was suspended when GMPI appeared because of the potential of a truly
cross-platform API emerging from the effort.
to have 1-5 people go off and code up a prototype GMPI at this stage
will, i believe, totally fracture the process. we are already
*surrounded* by prototypes. prototypes are not the problem: reaching a
decision over which of several possibly pathways through the potential
design solutions is.
--p
----------------------------------------------------------------------
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:
