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

[Steve Harris]

On Mon, May 01, 2006 at 02:13:00AM +0200, Lars Luthman wrote:
> > > >  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.

I as thinking the host could call run(0), but I guess it might not want to
activate either.
 
> 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.

It's possible, but it looks a bit ugly to me, and theres no way to update
it without calling instantiate again.
 
> 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).

Or passing function poionters over control outs, but thats even nastier.

But if its a required host feature, then the mini-spec for the feature can
just say what the callback must be called.

- Steve