Subject: [linux-audio-dev] plugin ideas based on Guenter's mix plugin API
From: est_AT_hyperreal.org
Date: to elo 26 1999 - 14:34:31 EDT
Guenter Geiger discourseth:
>
> If people want to try their favorite filter, effect or the like within
> mix, go ahead programming a plugin, send me the code and suggestions
> how to make the API better :)
Here are my suggestions for the API taking it as a starting point for
a general plugin standard. I understand that Guenter may not have
intended it to be used for that purpose, but, in any case, I applaud
him for taking the lead on this by posting his API. :) I'm really
excited about the idea of coding to a spec that this list has worked
over. The prosepctive increase in functionality is dazzling. I hope
Guenter will put audioplug.h on the web for wider availability.
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.
* 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.
* 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.
* Change properties to a * int32_t to avoid binary compatibility concerns.
* Change sparebytes to a void * for the same reason.
* Change the prefix to something other than `st_' which has too much
history in unix. A three-character prefix would be much safer.
* Use uint32_t instead of u_int32_t for POSIX 1.g compatibility.
* 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.
* 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.
* 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.
* 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.
* The popup method should probably be expanded to a vector of generic
gui methods.
* Memory allocation hooks are probably desirable. That way I can get
a plugin to throw bad_alloc even if it know nothing about C++.
Hmm..enough for now. :)
Eric
This archive was generated by hypermail 2b28 : pe maalis 10 2000 - 07:25:53 EST