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

Dave Robillard drobilla at connect.carleton.ca
Mon May 1 20:50:13 UTC 2006


On Mon, 2006-05-01 at 21:24 +0100, Steve Harris wrote:
> On Mon, May 01, 2006 at 01:51:55 -0400, Dave Robillard wrote:
> > 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..
> 
> IMHO, thats not the way to do any of those things:
> 
> mono/stereo is best done with dosconnected ports IMHO. That way you can
> change the connected state and have the plugin react.

mono/stereo isn't the best example.  I'm thinking of things like an n->1
mixer plugin.

> FFT bin size should be a parameter of the FFT data, for the same reason.
> 
> MIDI buffer size again, and the output buffer size needs to be set by the
> plugin, it can be done in RF, or with a well-known control out port if it
> needs to be dynamic.

Both true.  I was reaching for examples other than the above one. :)

> > 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.
> 
> Perhaps, but if so, not for the reasons you say. It's only useful for
> things that mustn't change during one instantiation cycle, there aren't
> many things like that.

Admittedly the variable ports thing is the only use case I can really
think of at the moment.  I think you're right though, instantiation
parameters probably aren't the best way to achieve that, the number of
ports could be provided as a field of the struct the same as MIDI buffer
sizes.  That's probably better and more consistent; though has the same
problems with plugin providing the output and being able to allocate the
ports (or dictate how many the host allocates) that MIDI output has.

I guess the port things aren't a good justification for the creation
parameters, you're right.  The question, then, is what is the
recommended way for the host to provide functions to the plugin?  That's
what Lars was originally seeking (and solves the above allocation
problem as well)
 
-DR-





More information about the Linux-audio-dev mailing list