Subject: Re: [linux-audio-dev] plugin ideas based on Guenter's mix plugin API
From: est_AT_hyperreal.org
Date: pe elo 27 1999 - 17:06:57 EDT
Guenter Geiger discourseth:
[re properties]
>
> But I'm not completely against dynamic allocation ... just some
> points why it isn't that important here, ...
Yes, I agree now that I better understand your approach to properties.
> > 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.
Hmm..perhaps we can come up with a colorful alternative expansion of
the acronym. I'll give it some though.
> > 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,
..for various values of nchannels, yes.
> which is actually contraproductive.
> We will just get more incompatible plugins.
We'll get incompatible plugins, yes..*and* we'll get more code reuse.
> 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 ?
These are certainly real downsides. Our goals and trade-offs may be
different..and I'd like a spec that accomodates different
goals..especially given the variety of them on this list. :)
Eric
This archive was generated by hypermail 2b28 : pe maalis 10 2000 - 07:25:53 EST