[gmpi] Re: Reqs section 3.6
- From: "Vincent Burel" <vincent.burel@xxxxxxxxxx>
- To: <gmpi@xxxxxxxxxxxxx>
- Date: Tue, 2 Dec 2003 11:16:16 +0100
----- Original Message -----
From: "Tim Hockin" <thockin@xxxxxxxxxx>
To: <gmpi@xxxxxxxxxxxxx>
Sent: Tuesday, December 02, 2003 5:22 AM
Subject: [gmpi] Re: Reqs section 3.6
> On Tue, Dec 02, 2003 at 08:47:44AM +0100, Vincent Burel wrote:
> > req 17 : at least one part of the plug-in must run in the Host adresse
space
> > (something like the primary interface... we have to give a name to that,
> > maybe the CORE should be ok).
>
> It should be safe to say the the GMPI plugin runs in the host's native
> address space. There may be another part, but the GMPI part is native.
> Always.
ok,
> > req 18 : MUST present a native interface (do you mean a native
processing
> > function !?) this is not clear.
>
> TO be called a GMPI plugin you must taste like a GMPI plugin. There is
one
> flavor of GMPI. What your GMPI plugin does internally is totally hidden.
> You can run code on a DSP card, send stuff across the network, read data
> from an ADC, or anything else. GMPI doesn't handle that.
ok, but it's redondant with req 17 in this case.
> > req 19 : yes... maybe not enough precise, but ok for the moment.
>
> what is missing?
some cases... is the buffer size can change, in which condition (maybe
conversion off-line plug-in) etc...
> > req 21 : i'm not very agree with that. I consider that the Host has to
be
> > seen as an over-system, so he has to provide such access...(for example
in
> > order to be able to share this kind of resource... )
>
> This req is probably redundant with #18. Beneath the skin of GMPI, a
plugin
> can do ANYTHING IT WANTS, as long as it doesn't break the rules of GMPI.
It
> might not work in all hosts or in all circumstances, but it should be
> possible to work. For example, a host MAY decide to implement
audio-inputs
> and outputs as plugins.
don't like this idea. I don't want to deal with a full generalist plug-in
SDK like Direct-X. There is two main issue in programming job. To know who
do what (what components or part of the software takes care about this or
that) and to find a compromise between the full generalist architecture and
a dedicated one. I would like to let the GMPI plugger, be focused on the
significant task : audio processing according incoming parameters (again to
improve the plug-in production process).
you are talking here about Audio in/out, and why don't talking about sony 9
Pin, Firewire, VST Link , etc... etc... I don't know how you want GMPI be
general plug in architecture, but me i would like to limit the SDK to the
processing and virutalize simply the datas/parameters/context communication.
VB
----------------------------------------------------------------------
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:
