[linux-audio-dev] Plugin APIs (again)

Conrad Parker conrad at vergenet.net
Tue Dec 3 01:00:01 UTC 2002


Hi Tim,

I like the style of your proposed API. A few comments:

*) Scope: your stated goal is to produce an API that is "full-featured
   enough to be the primary plugin system for an audio-development
   application". I think it would be more correct to say that this is
   an API designed for virtual instrument plugins, with a programmatic
   rather than GUI interface (as LADSPA is for effects plugins).

   This is not a bad thing, in fact I think we are better served with
   small, focussed plugin APIs for specific tasks -- and virtual
   instruments and effects are two very worthwhile specific tasks.
 
   Also, there are plugins that cannot be accomodated by this API; eg.
   causal plugins (eg. reversal of large buffers), plugins for which
   nsamples in != nsamples out (eg. time stretching and rate conversion),
   and plugins which need to do a number of passes (eg. GWC's noise
   reduction needs to profile some quiet data in a first pass); not to
   mention that this plugin implies time domain manipulation only.

   I don't think the scope of your API should be expanded to include
   these, as it would lose much of its elegance -- it would be awful to
   clutter the common cases (instruments and effects) just for the needs
   of offline and highly analytic plugins. However I would suggest that
   you refine the stated scope (eg. instruments and inline effects) and
   concentrate on doing a good job of that.

*) Note control: I prefer your first method (separate voice_on() and off()
   functions, rather than a single voice_ctrl() function) -- for the
   same reason that "ioctls are bad, mmkay" and syscalls are good, ie.
   there's no need for a cryptic overloaded control function, especially
   here to implement only a well defined set of operations.

*) Identifying controls: It would be quite useful to share the same get()
   and set() functions between a number of controls (eg. similar sliders
   of an equaliser), for which you would want eg. an int parameter
   identifying the control index. (In those situations, making a bunch of
   tiny interface functions within the plugin is pretty ugly).

*) Descriptions: It'd be nice to supply both short and long descriptions
   for controls as well as for the whole plugin.

that's it from me for now; nice work overall, I like that it treats
multiple channels coherently and handles enum and string inputs, that
makes generated GUIs a lot nicer :)

Conrad.



More information about the Linux-audio-dev mailing list