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

On Sat, 2006-04-29 at 18:25 +0100, Steve Harris wrote:
> On Sat, Apr 29, 2006 at 12:42:14PM -0400, Dave Robillard wrote:
> > > With the port types specified in the RDF file, MIDI input should be
> > > doable with explicit LADSPA2 ports of some defined MIDI type, which
> > > means that we wouldn't need the run_synth() callback. The GUI
> > > specification and the OSC protocol is already pretty much applicable to
> > > LADSPA as well as DSSI, so that should work in LADSPA2 too. New
> > > additions like MIDI output and transport info could also be done as port
> > > types.
> > >
> > > The things that aren't obvious how to do are
> > >
> > > 1) the configure() callback
> >
> > OSC message.
>
> Thats a little laconic, even by my standards :) To my mind the key thing
> about configure() is that it happens outside the RT context, and
> LADSPA-style plugins have no easy way of running an OSC server of thier
> own.
>
> > > 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.
>
> Control port :|

Not really - plugins only get to write to the control ports in the run()
callback (or select_program() for DSSIs), and it's entirely possible and
plausible that a program would want to list the available programs for a
plugin before it starts running it's audio callback.

Would it be possible to change the instantiation function from

  LADSPA_Handle (*instantiate)(const LADSPA_Descriptor* Descriptor,
                               unsigned long SampleRate,
                               const char* BundlePath,
                               const char** HostFeatures);

to something like this:

  LADSPA_Handle (*instantiate)(const LADSPA_Descriptor* Descriptor,
                               unsigned long SampleRate,
                               const char* BundlePath,
                               const char** HostFeatures,
                               void** HostFeatureData);

where HostFeatureData is a NULL-terminated array of the same size as
HostFeatures, containing feature-specific data that the plugin can read
and/or write. Then, if HostFeatures[3] is "PROGRAM_LIST_CALLBACK",
HostFeatureData[3] can point to a 'const DSSI_Program_Descriptor
*(*)(LADSPA_Handle, unsigned long)', i.e. a DSSI program list callback
pointer, and the plugin can set it to point to its program list
callback. Or you could define a "DSSI" host feature and a struct similar
to the current DSSI_Descriptor with configure(), get_programs(),
get_midi_controller_for_port() etc and pass a pointer to that instead.

I don't see any other obvious way to let future extensions add their own
callbacks (except for specifying a function name in the RDF file and
then dlsym()ing that symbol name in the host).

-- 
Lars Luthman
PGP key:     http://www.student.nada.kth.se/~d00-llu/pgp_key.php
Fingerprint: FCA7 C790 19B9 322D EB7A  E1B3 4371 4650 04C7 7E2E