1 May
2006
1 May
'06
6:50 p.m.
On Mon, 2006-05-01 at 21:24 +0100, Steve Harris wrote:
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-
On Mon, May 01, 2006 at 01:51:55 -0400, Dave Robillard
wrote:
mono/stereo isn't the best example. I'm thinking of things like an n->1
mixer plugin.
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.
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.