29 Apr
2006
29 Apr
'06
4:07 p.m.
On Sat, Apr 29, 2006 at 06:43:14PM +0100, Chris Cannam 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.
Agreed.
- Steve
On Saturday 29 Apr 2006 17:42, Dave Robillard wrote:
Not entirely in RDF, the RDF is just used to identify the structure, and
and constant parameters to it. The definition of it can be done in
whateve'rs the most approariate way (C struct in a headerfile for
example).
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.