1 May
2006
1 May
'06
6:25 p.m.
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.
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
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