[gmpi] Re: Out-of-Band: suggestion for rethink
- From: "Vincent Burel" <vincent.burel@xxxxxxxxxx>
- To: <gmpi@xxxxxxxxxxxxx>
- Date: Wed, 24 Sep 2003 16:06:59 +0200
----- Original Message -----
From: "Paul Davis" <paul@xxxxxxxxxxxxxxxxxxxxx>
To: <gmpi@xxxxxxxxxxxxx>
Sent: Wednesday, September 24, 2003 3:41 PM
Subject: [gmpi] Re: Out-of-Band: suggestion for rethink
> >I'm also against to review or use any existing SDK's because this is not
the
> >best way to share the experience of the GMPI people group. To design and
> ^^^^^^^^^
>
> that is what we are attempting to do.
>
> >program a base minimal SDK would be the only one way to share really our
> ^^^^^^^^
>
> that is also what we are attempting to do, after we have a basic
> design in place.
>
> the question at the moment is: what process works best for collecting
> requirements? i think there is empirical evidence that the method we
> have been using is running out of steam. your alternative, which i'll
> describe with the inaccurate but short phrase "lets write some code",
> doesn't address *how* we go about figuring out just what the GMPI API
> should do.
No, there is minimum that we can do without anyrequirement but a small goal
(e.g. a basic host wants to load a simple delay/gain somewhere) until today
we try to build a Pyramide by the TOP . sorry no, we need fundations , our
fundation : our common fundation.
Well, that i propose is to build the minimum not the maximum. And in our
problem this minimum exist and cannot be removed whatever the final goal
(maybe the formalism will change a bit but not fondamentally the kernel).
This first "lets write some code session" will oblige us to design the
common base that everybody will know at 100% and will be able to arg on.
there is 3 small projects to build
- 1 - a basic host
- 2 - a basic GUI with controls for example.
- 3 - a basic FX
In a very first step , we can program that, separately with different team.
And we will stop when one project will have to communicate to an other one
(certaineley the first question will come from the team who does the Host :
where is the plug-in ? )
the goal is firstly to produce a basic system that enable a user to load and
use a basic plug-in, (This can be done by providing around 5 functions per
project - for the FX it could be Create / Destroy / Process / Set/Get
Context) and think together about the formalism of the software interface,
source code organization, and programming low. It's the very first step.
> i would guess that many people are itching to write some code. most of
> us appear to think its a good idea to understand what we're trying to
> write before we start, not because this is always necessary
> (particularly not when doing something innovative), but precisely
> because GMPI is **NOT** innovative in any technical sense.
I don't talk about innovation, and franckly i wish that the code we could
produce and the method we will use won't be innovative at all but simple and
idiot , because it's the code i prefer, and my computer too ! :-)
The problem is that this question of producing something (in term of source
code) together will be there at a moment or another. If we are not able to
do that right now on so trivial project, i think we won't never be able to
do.
> GMPI appears to me to be born from two distinct feelings:
>
> * the control issues with proprietary plugin APIs
> * technical issues with existing plugin APIs
Yes , but all these points will appear , clearly and quickly to evereybody,
if we are talking about the same thing : a common software project.
> the control issue is addressed merely by the existence of this
> forum. the technical issues might come to light better by talking
> about them in the context of specific APIs.
This can help, but this cannot be as efficient than the way i proposed. For
example VST SDK , is interesting by the simplicity of the implementation. In
an other hand, this SDK does not make appear many problem that people meet
in a real situation. And personnally i think that most plug-in SDK's have
not been build in a real situation, means with people who program the host
and people who program effect and people who program user interface and so
on , in the same time, with a hard discussion between all parts.
This last point is also a good advantage that we could use here.
Vincent Burel
----------------------------------------------------------------------
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:
