Subject: [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 - 06:52:04 EDT
est_AT_hyperreal.org writes:
> Guenter Geiger discourseth:
> Note that these suggestions take the contents of the strummin
> directory as their context. Many of my suggestions may be based on
> ignorance or misunderstandings.
>
Go ahead and beat me ... I like it :)
> * The whole thing should move to a class/instance paradigm so I can
> instantiate multiple instances of a plugin. Parameter descriptions
> should be in the class and their values in the instance, etc.
>
Agreed, I only realized the problem when I was heavily hacking mix
again ... as a quick hack I was about to implement a clone()
function.
The idea with that was, that the new functions of any plugin sets
the default values after cloning.
> * 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 ..
> * 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. In the current case we just get back a default value.
Of course, now we can only extend the properties until we have
reached MAXPROPERTIES.
>
> * 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.
> * Use uint32_t instead of u_int32_t for POSIX 1.g compatibility.
>
changed immediately
> * The param/type field needs some definition and should have an enum
> type.
>
> * We want to be able to say that a param must be integral.
>
> * There should be a parameter default value field along with a flag so
> say whether it's valid.
>
> * String parameters should be provided for.
>
> * We need a flag to say whether a parameter can be modified in between
> any two calls to the process method as opposed to being settable only
> for initizlization purposes.
>
We should discuss parameters separetely ....
> * 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.
> * 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.
>
> * 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 ?
Yes, the return value of process is the number of samples created.
(Note: I'd like to avoid frames, we could add a data format for
interleaved stereo data, though).
> * The popup method should probably be expanded to a vector of generic
> gui methods.
>
As few as possible, but right, we may need more .....
> * Memory allocation hooks are probably desirable. That way I can get
> a plugin to throw bad_alloc even if it know nothing about C++.
>
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.
The application can decide which kind of plugins it will support.
Audiality may probably only support plugins which claim to be
realtime, whereas some other applications don't care about that.
The API should be flexible enough for plugin programmers to implement
their ideas, but keeping them to certain contraints.
Guenter
This archive was generated by hypermail 2b28 : pe maalis 10 2000 - 07:25:53 EST