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

[Dave Robillard]

On Mon, 2006-05-01 at 02:13 +0200, Lars Luthman wrote:
> 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);

Eeeww.  I like the hostfeatures idea, but don't do parallel arrays, make
a struct:

struct HostFeature {
    char* name;
    void* data;
}

Though I don't think this is the right way of going about this.  We
should leave HostFeatures as is and add instantiation parameters (as a
few people have requested) with the above form.  You could define a
HostFeatures that guarantees a certain parameter will be there to get
what you want.  Something like:


struct LADSPA_Parameter {
    char* name;
    char* data;
}

LADSPA_Handle (*instantiate)(const LADSPA_Descriptor* descriptor,
                             unsigned long            sample_rate,
                             const char*              bundle_path,
                             const char**             host_features,
                             const LADSPA_Parameter** parameters)


Basically the same as Lars' proposal above, slightly remixed to make it
more general and useful.

This is needed, among other things, for eg. variable number of ports
support (through a special port type), which is an extension I would
REALLY like to be possible (one plugin, stereo/mono support).  Things
like FFT bin size, MIDI buffer size, etc. could also be parameters.
There's heaps of possible uses..

Semantics:  the parameters should be completely optional, and the plugin
MUST NOT fail to instantiate based on the lack of a necessary parameter
(unless that is specified as a HostFeatures).  It could also be used to
passs function pointers to the plugin as Lars suggested, which would be
very nice, but given what happens if something gets messed up
(SEGFAULT), I don't know if this is the best mechanism to provide that.

(This isn't really a 'new feature' so much as HostFeatures done right
IMO)

Thoughts?

-DR-