Subject: Re: [linux-audio-dev] plugin ideas based on Guenter's mix plugin API
From: est_AT_hyperreal.org
Date: pe elo 27 1999 - 14:30:11 EDT
Guenter Geiger discourseth:
> est_AT_hyperreal.org writes:
> > Many of my suggestions may be based on
> > ignorance or misunderstandings.
>
> Go ahead and beat me ... I like it :)
Ahh..well, it *can* be fun in the pursuit of a good design, no? :)
> > * The only global defined by a plugin should be a uniquely named
> > function that returns a plugin class. The idea here is to make it
> > possible to use static as well as dynamic linking.
> >
>
> .. hmmm seems to make sense ..
I'm not particular about the exact interface, as long as static
linking isn't precluded.
> > * Change properties to a * int32_t to avoid binary compatibility concerns.
> >
> > * Change sparebytes to a void * for the same reason.
>
> 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.
> > * 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.
> > * 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).
> > * The sample rate should be optionally settable at instance creation
> > time and the input and output buffer sizes should be optionally
> > settable per call to the process method. I usually code in a way that
> > can accomodate this, but I agree that it's important to support less
> > flexible plugins as well.
>
> It's possible to set these things whenever you like.
> The plugin programmer can decide which properties can be changed,
> and which not. That's what the virtual verify function is all about.
Hmm..I'm wondering if there should be a harder distinction between
properties and parameters re mutability.
> > * To handle resampling, variable output buffer sizes are important.
> > It's also important that the process method can report how many output
> > frames it generated (is this the function of the return value of the
> > process method?). It may even be important that the plugin can
> > be queried as to how many output frames *will* be generated to avoid
> > overruns due to disagreements about fencepost issues.
>
> Isn't it enough to have different sizes for input and output buffers ?
I take back most of this and I think the issue will need some careful
thought, especially considering David Olofson's comments.
> > * The popup method should probably be expanded to a vector of generic
> > gui methods.
> >
>
> As few as possible, but right, we may need more .....
Maybe config_dialog(), show(), hide() and a gui type string?
> Generally, I'm open to give write access to the CVS to whomever likes.
> I'm accepting patches too, of course. The first thing we have to
> agree upon is the API itself. Internal concepts can be implemented
> and tested after that.
I agree 100%.
Eric
This archive was generated by hypermail 2b28 : pe maalis 10 2000 - 07:25:53 EST