On Sat, Apr 29, 2006 at 06:43:14PM +0100, Chris Cannam wrote:
> 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?
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).
> > > 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.
Agreed.
- Steve
Received on Sun Apr 30 00:15:06 2006
This archive was generated by hypermail 2.1.8 : Sun Apr 30 2006 - 00:15:06 EEST