29 Apr
2006
29 Apr
'06
3:42 p.m.
On Saturday 29 Apr 2006 17:42, Dave Robillard wrote:
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.
On Sat, 2006-04-29 at 17:24 +0200, Lars Luthman
wrote:
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?
The things that aren't obvious how to do are
1) the configure() callback
OSC message. 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. > 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