1 May
2006
1 May
'06
3:52 p.m.
On Mon, 2006-05-01 at 02:13 +0200, Lars Luthman wrote:
On Sat, 2006-04-29 at 18:25 +0100, Steve Harris
wrote:
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-
On Sat, Apr 29, 2006 at 12:42:14PM -0400, Dave
Robillard wrote:
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.
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); 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. 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.