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

[Lars Luthman]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 191 bytes
Desc: This is a digitally signed message part
URL: <http://lists.linuxaudio.org/pipermail/linux-audio-dev/attachments/20060501/4e632aea/attachment.pgp>