[gmpi] Re: Reqs 3.8
- From: David Olofson <david@xxxxxxxxxxx>
- To: gmpi@xxxxxxxxxxxxx
- Date: Thu, 11 Dec 2003 21:28:26 +0100
On Thursday 11 December 2003 21.02, Jeff McClintock wrote:
> >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...
Actually, the feature is meant for GMPI plugins that "taste" native
but do their processing on external DSP hardware. When chaining
plugins running on the same DSP farm, the idea is to transfer data
internally, rather than piping it back and fort between the host and
the DSP farm between each plugin.
My "abuse" comment was just an observation; a feature that allows this
kind of things would also allow native plugins to bypass the host. A
bonus feature, basically - but I have to agree; I don't feel very
good about native plugins doing it, which is why I called it
"abuse"...
> Is this an argument for multiple sample types?
If native plugins would actually do this; yes, definitely. However,
the "bypass connections" thing was actually meant for plugins not
doing their processing on the host CPU; that is, a different issue.
> 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
That would be the *real* way of doing it, IMHO, but is it useful
enough to motivate the complexity? I'm not sure. It looks very
interesting to me, but I can't really prove that it's seriously
useful in the kind of environments GMPI is targetting.
> Just to be clear, I'm not saying a typical user's setup would
> include mixtures of float plugins and fixed-point plugins.
Yeah, that's the argument for compile time profiles, and not really
designing for mixing plugins using different profiles. Hosts could do
that anyway, but it's almost a cross-platform binary compatibility
hack. (Kind of like running Win32 VST plugins on Linux/x86 or
something; doable but hairy, and not explicitly supported by the
plugin API.)
> 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).
Yeah... Maybe per-pin datatypes won't make that much of a difference,
if we have to drag in multiple datatypes in some form anyway? Might
as well do it properly, if we have to do it at all.
> 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.
Makes sense, but it does impact "single profile" hosts and plugins
slightly. However, I think that can be restricted to something like
this:
* All plugins mark their audio ins and outs with
the ID of the sample format they're using.
* Hosts compare sample format IDs when making
connections. Hosts may refuse to make connections
with sample formats they don't know about, in
order to avoid added buffer management complexity
and compatibility issues with integrated DSP code.
Using the SDK, I think this "added complexity" could be reduced to
nothing for plugins as well as hosts, by making one sample format
only the default. (Platform dependent default format; usually float.
If you want something else, just say so, and for hosts, maybe adjust
the buffer management code a bit.)
//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
Other related posts:
