[gmpi] Re: Topic 3: Cross platform
- From: "Vincent Burel" <vincent.burel@xxxxxxxxxx>
- To: <gmpi@xxxxxxxxxxxxx>
- Date: Mon, 10 Mar 2003 23:55:53 +0100
----- Original Message -----
From: "Paul Davis" <paul@xxxxxxxxxxxxxxxxxxxxx>
To: <gmpi@xxxxxxxxxxxxx>
Sent: Monday, March 10, 2003 4:47 PM
Subject: [gmpi] Re: Topic 3: Cross platform
> i agree with this wording, but the point i was trying to convey was
> that the calling convention is just one part of the cross-platform
> picture. its clear that we do have to define the calling convention to
> cover those platforms where it varies. but i've also tried to
> establish that there are other things that plugins need to do for
> which the only option right now is a platform-specific approach. so i
> guess to restate this in the form you've chosen, i can see 3 options:
>
> a) the GMPI specification should not address how plugins access various
> system resources and configuration information.
>
> b) the GMPI specification should include a definition of how a plugin
> can access various system resources and configuration
> information. it should also define which resources and
> information are available in this way.
>
> c) the GMPI specification will reference/encourage use of another
> specification to allow plugins to access various system
> resources and configuration information.
>
> which should it be?
i don't know if i understand exactely the question but i give a response :
b) but much more !
Let's think the plug-in SDK like an industrial process. Industrial Process
means all problems , all issues, all methods are identified, explained,
solved, described, documented, known. There is no mystery, no good luck or
bad luck , there is a strict step by step.
Also the cross platform might not be a problem is the source sections are
well documented. well documented means doing a list of what third part
programmers can do exactely, how in term of method , and where in the source
code exactely.
well GMPI sdk , in my opinion , has to take in charge all usual needs
(related to the SDK) of third part programmer in building a plug-in (where
initialize global, how, when initialize private buffer, how to communicate
parameters with GUI and Processing, how to manage automation, M.I.D.I., etc,
etc, etc....)
Vincent Burel
PS : instead of talking in the air to say and produce finally nothing (i
talk for me, because my experience shows me that when i talk, i don't
produce, but it's maybe just for me :-) perhaps we could try a kind of game
: one group is doing the host , the other make the plug-in. We begin by a
simple host (just pure audio multitractrack for example) and a simple
plug-in (an equalizer for example). Then we begin the discussion ! -"hey
plug-in !? where are you !?" -"i'm in the registry or in the file
plug.list" -"what is your name ?" -"My name is Bond, James Bond !" ... ok,
just an idea to animate the debat...
----------------------------------------------------------------------
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:
