[gmpi] Re: Reqs 3.8
- From: "Jeff McClintock" <jeffmcc@xxxxxxxxxx>
- To: <gmpi@xxxxxxxxxxxxx>
- Date: Fri, 12 Dec 2003 09:02:34 +1300
>BTW, one could "abuse" that feature to optimize the connections
>between related native plugins. ... they can
>bypass the host and transmit FFT buffers instead of time domain audio
>buffers. Or integer audio buffers, or whatever...
That's very bad (plugins bypassing the host via secret hacks). It implys
the plugin API is insufficient...
Is this an argument for multiple sample types?
i.e. each 'pin' specifies it's sampletype?
Some examples of plugins:
* float-in/float-out,
*fixed-in/fixed-out,
or (less common)
*float-in/FFT-out
*float-in/fixed-out
Just to be clear, I'm not saying a typical user's setup would include
mixtures of float plugins and fixed-point plugins.
Only that instead of specifying datatype at compile time, datatype would
be specified per-pin in the plugin's metadata.
(As before, The host might support only one 'profile' (e.g.
float-in/float-out plugs only).
Advantage is:
-All GIMPI plugins use the same SDK.
-All Plugin dll's share the same interface/signature (easier for host to
deal with).
-A cell phone type platform can 'evolve' via a transition period where both
fixed and float plugs are in use.
As usual, just throwing ideas arround. I'm not too worried about this.
Best Regards,
Jeff
----- Original Message -----
From: "David Olofson" <david@xxxxxxxxxxx>
To: <gmpi@xxxxxxxxxxxxx>
Sent: Friday, December 12, 2003 6:03 AM
Subject: [gmpi] Re: Reqs 3.8
On Thursday 11 December 2003 17.29, RonKuper@xxxxxxxxxxxx wrote:
> Normally, yes, but unless we actively prevent it, people could load
> integer plugins into float hosts and vice versa, resulting in
> "mysterious" crashes. <<<
>
> People would only load whatever plugins into the host that the host
> allows. If plugins have profiles (in meta-data) and way to
> enumerate them, then I can't imagine a case where a host wouldn't
> know exactly what kind of plugin it was instantiating. If we're
> worried about that, we could make the API require the host to pass
> in a kind of profile identifier when creating a plugin of a
> particular profile. That way, if the host wants floats, and tries
> to create an int with a float "cookie", the int will fail to load.
Yeah, something like that. I just want something like this in the
requirements, so we don't end up with multiple binary "compatible"
profiles and no way to tell them apart at run time.
As to DSP based plugins and stuff like that (ie plugins that bypass
the host's connection system), that was concluded earlier to be a
separate issue, right? (Plugin private business; GMPI has to provide
some way for plugins to take over when connections are made to
"friends" under certain circumstances.)
BTW, one could "abuse" that feature to optimize the connections
between related native plugins. For example, when some FFT based
plugins are chained, they could eliminate frequency->time->frequency
where appropriate. That is, when they see local friends, they can
bypass the host and transmit FFT buffers instead of time domain audio
buffers. Or integer audio buffers, or whatever...
//David Olofson - Programmer, Composer, Open Source Advocate
.- Audiality -----------------------------------------------.
| Free/Open Source audio engine for games and multimedia. |
| MIDI, modular synthesis, real time effects, scripting,... |
`-----------------------------------> http://audiality.org -'
--- http://olofson.net --- http://www.reologica.se ---
----------------------------------------------------------------------
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
----------------------------------------------------------------------
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:
