Subject: Re: [linux-audio-dev] Plugin APIs (again)
From: Conrad Parker (conrad_AT_vergenet.net)
Date: Tue Dec 03 2002 - 07:54:38 EET
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.
This archive was generated by hypermail 2b28 : Tue Dec 03 2002 - 08:00:50 EET