linuxaudio.org

On Mon, May 01, 2006 at 01:51:55 -0400, Dave Robillard wrote:

quoted text
> 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.
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.
> Semantics:  the parameters should be completely optional, and the plugin

quoted text
> 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.
- Steve