30 Apr
2006
30 Apr
'06
10:13 p.m.
On Sat, 2006-04-29 at 18:25 +0100, Steve Harris wrote:
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);
where HostFeatureData is a NULL-terminated array of the same size as
HostFeatures, containing feature-specific data that the plugin can read
and/or write. Then, if HostFeatures[3] is "PROGRAM_LIST_CALLBACK",
HostFeatureData[3] can point to a 'const DSSI_Program_Descriptor
*(*)(LADSPA_Handle, unsigned long)', i.e. a DSSI program list callback
pointer, and the plugin can set it to point to its program list
callback. Or you could define a "DSSI" host feature and a struct similar
to the current DSSI_Descriptor with configure(), get_programs(),
get_midi_controller_for_port() etc and pass a pointer to that instead.
I don't see any other obvious way to let future extensions add their own
callbacks (except for specifying a function name in the RDF file and
then dlsym()ing that symbol name in the host).
--
Lars Luthman
PGP key: http://www.student.nada.kth.se/~d00-llu/pgp_key.php
Fingerprint: FCA7 C790 19B9 322D EB7A E1B3 4371 4650 04C7 7E2E
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.