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

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.