Subject: Re: [linux-audio-dev] plugin ideas based on Guenter's mix plugin API
From: David Olofson (audiality_AT_swipnet.se)
Date: pe elo 27 1999 - 22:32:36 EDT
On Fri, 27 Aug 1999, Guenter Geiger wrote:
> 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, ...
To me it starts to look like 3 levels are needed:
Properties:
Hardcoded in the plug-in class.
Parameters:
"Firmcoded" in a plug-in instance.
Can be changed, but this may result
in a non real time response.
(For example, changing the patch
on a sampler may require that you
wait for data to load from disk
before the plug-in handles further
events.)
Controls:
Used for real time control, and
should *always* be real time.
(That is, a "controller change"
event shouldn't result in the
plug-ins requesting to go off-line
for half a second...)
The bondaries are still a bit vague, so there should probably be some way to
tell the host what will happen when certain parameters and controls are
changed. Or do these categories cover everything? Need to think some more about
this...
> > > > * 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.
OMPIS... Open Multimedia Plug-In Specification. *hehe*
No, seriously, should we try to give a hint as to what the main use of the
standard is, or not? Open Plugin Specification is perhaps a bit too
non-specific, but OpAPS, Open Audio Plug-in Specification probably doesn't
cover all areas where it can be used... Kind of a marketing decision.
> 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.
See my comment on SIMD processing and the cost of splitting/merging... I don't
think it's all that bad really, but my opinion is still that mono signals
make everything more flexible without the complexity. One point to the mono
signal team.
SIMD instructions are cool, though, and organizing the data in the engine
might have some advantages over doing it in the plug-ins. And, as I think I've
stated before (perhaps not here, though), complexity - if it cannot be avoided
altogether - should be in the engine and not in the plug-ins. So that's one
point to the multichannel signal side...
//David
·A·U·D·I·A·L·I·T·Y· P r o f e s s i o n a l L i n u x A u d i o
- - ------------------------------------------------------------- - -
·Rock Solid David Olofson:
·Low Latency www.angelfire.com/or/audiality ·Audio Hacker
·Plug-Ins audiality_AT_swipnet.se ·Linux Advocate
·Open Source ·Singer/Composer
This archive was generated by hypermail 2b28 : pe maalis 10 2000 - 07:25:53 EST