Subject: Re: [linux-audio-dev] plugin ideas based on Guenter's mix plugin API
From: Guenter Geiger (geiger_AT_epy.co.at)
Date: pe elo 27 1999 - 16:23:15 EDT
est_AT_hyperreal.org writes:
> > Yep, dynamic allocation, but then, if we want to access (some later added)
> > properties we always have to check if the plugin has allocated memory
> > for them.
>
> You've got that covered by numproperties.
>
Yes, but actually we don't want to expand the number of properties
(it's surely not something the plugin should be able to do).
The properties are hardcoded into the spezification, they are just
like the flags in VST or some variables that have to be set by each
plugin.
Only in emergency cases (If we find a problem with our plugin API
or somthing needs a new kind of plugins they will be extended).
But I'm not completely against dynamic allocation ... just some
points why it isn't that important here, ...
> > > * Change the prefix to something other than `st_' which has too much
> > > history in unix. A three-character prefix would be much safer.
> > >
> >
> > Agreed too, stm_ probably, I'm open to better names for the API too,
> > strummin doesn't sound very professional, I just thought it's funny.
>
> Hmm..I still favor my earlier suggestion of `ops', for `Open Plugin
> Specification'. It's pronouncable, appropriate and short enough for a
> prefix.
>
ops sounds cool, but .... well Open Plugin Specification sound rather
.. not very inventive .. but probably what we need for some people
to accept the API.
> > > * The number of channels per input and output signal should be a
> > > plugin property vector. Counts of frames and samples should be
> > > clearly distinguished throughout.
> > >
> >
> > Basically I'd like to have each channel on a seperate input.
> > We have to set some restrictions, as through flexibility we
> > will make it harder to write applications for the plugins,
> > and introduce too much incompatibility.
>
> I want multi-channel support pretty badly. I certainly appreciate the
> flexibilty of a mono-channel paradigm, but I think there are
> situations where multi-channel makes sense. For example, scope
> plugins will often want stereo input. Kai has also pointed out some
> of his needs in this area. Further, I've found that stereo data is a
> sitting duck for hefty 3dnow acceleration. It doesn't seem reasonable
> to make plugins that want multi-channel input do their own merging
> when merging/splitting can be trivial standard plugins.
>
> One restriction that no one might find objectionable is that the input
> signals and output signals of a plugin both be homogeneous with
> respect to the number of channels. Then you only need inchannels and
> outchannels parameters for the plugin. If you want mono, just make
> sure these are both 1 (which could be the default).
>
Ok, if we accept that it's just like adding
DATAfloatstereo
DATAint32stereo
DATAdoublestereo
to the dataformat enum, which is actually contraproductive.
We will just get more incompatible plugins.
Keeping channels separated in different streams is a more
profesional approach, because sometimes I really do think of
let's say 4 channel spatialisation .... will this be 2 stereo
channels, 4 mono channels , or 4 channel interleaved ?
so, I'm still against it, I'd like to hear other comments too.
Guenter
This archive was generated by hypermail 2b28 : pe maalis 10 2000 - 07:25:53 EST