[linux-audio-dev] Todays changes to "LADSPA2" strawman

[Chris Cannam]

On Saturday 29 Apr 2006 17:42, Dave Robillard wrote:
> On Sat, 2006-04-29 at 17:24 +0200, Lars Luthman wrote:
> > The things that aren't obvious how to do are
> >
> >  1) the configure() callback
>
> OSC message.

And there you've introduced something I haven't seen in this thread yet: 
sending messages rather than just values to your plugin.  How come 
there are dozens of posts here talking about the name of the API and 
bitching over whether this "extensible" plugin API should start out 
with a logarithmic port hint, when things like this are going 
unmentioned?

Is the expectation that any plugin be able to define that a certain port 
accepts any given structure of data, defined entirely in the RDF?  Or 
what?

> >  2) the dynamic program lists and midi mappings (static definitions
> >     could be written in the RDF file, but that's no fun)
>
> That's a tougher one.
>
> >  3) program selection
>
> OSC message.

You see that's all terribly glib, but the things that make the non-GUI 
parts of DSSI complex are not so much about how data is passed to and 
from the plugin as when it is passed, what the dependencies between 
things are (e.g. when you change a configure value, the programs may 
change; when you change a program, the ports may change), what the 
threading requirements are and so on.  An entirely generic anything-in 
anything-out plugin is unlikely to be much actual use, in practice.

> >  4) the run_multiple*() callbacks (how many plugins use these?)

Hexter, Xsynth, WhySynth etc.

run_multiple is DSSI's equivalent of MIDI channels. 

There is no channel information in the note messages passed to a plugin; 
instead the host creates as many instances as it needs, effectively one 
instance per channel, and run_multiple allows the plugin to share work 
between them if appropriate.  If it has no work to share, it just 
doesn't bother providing this function.

This can have advantages for the plugin (the simple case is simpler) and 
user (any plugin appears able to receive any number of channels of 
input, without the user's having to know what the plugin's actual 
configuration is).  The main disadvantage is simply that it's different 
from how other MIDI-based APIs work.  In my view it's better in 
isolation -- in a homogenous environment -- but can become awkward when 
mixed with actual MIDI devices.


Chris