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

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-
Received on Tue May 2 00:15:03 2006