Subject: [linux-audio-dev] LADSPA extension proposal (quick action wanted)
From: Paul Davis (pbd_AT_Op.Net)
Date: Thu Dec 06 2001 - 16:13:45 EET
2 proposals for changes to LADSPA, with the intent of moving LADSPA
v1.0 to LADSPA v2.0.
over on ardour-dev, we've been discussing a new protocol (the LADSPA
Control Protocol; implemented) to allow standalone GUIs to control
LADSPA plugins via a host. the GUI has no direct knowledge of the
plugin - it just reads/writes port data from/to the host, which is
responsible for acting upon it. these two proposed changes arise from
this.
--------------
1) control ports that accept arrays of LADSPA_Data
steve harris, aka "Mr. LADSPA himself" (i'm sure we all recognize that
steve has been by far the most prolific writer of distributed LADSPA
plugins to date) has mentioned his desire for this:
A better exmample: imagine a generic waveshaper, it has an
input->output curve that the user can manipulate (think
GtkGammaCurve), somehow you have to unambigiously get the data from
the curve into the plugin.
this is an old idea here: "this port accepts float[N]" I am not quite
sure how to implement this. changes to the header file are easy to
imagine, but its not clear how you would write the data to the control
port: it can't be done atomically, and you don't want the plugin
working with a partially overwritten data set. so, i can easily
propose changes to the header, but first, can someone suggest a way to
apply the new data?
--------------
2) GUI descriptor
i think the best idea we've had so far goes something like this:
typedef enum {
LADSPA_NATIVE_GUI,
LADSPA_LCP_GUI,
LADSPA_XML_GUI,
LADSPA_VST_GUI
} LADSPA_GUI_TYPE;
and then in the LADSPA plugin descriptor add:
char *gui;
LADSPA_GUI_TYPE gui_type;
for NATIVE_GUI, `gui' is the name of the executable containing the GUI
(no directory - to be found via LADSPA_PATH).
for LCP_GUI, `gui' is as for NATIVE_GUI, with the additional
constraint that the executable must understand two arguments:
-h host
-p plugin-id
which tell it how to use the LADSPA Control Protocol to manage the plugin.
for XML_GUI, `gui' is the XML text for the GUI
for VST_GUI, `gui' is the name of a file containing the object code
for a libvstgui gui, again no directory, found using LADSPA_PATH.
the `gui' member can be NULL. a host is free to ignore the `gui'
member. a plugin cannot assume that its self-provided gui will be
used.
------
Comments
We need a way to ensure that LADSPA v1.0 plugins can still be handled
by hosts that handle v2.0 as well. As far as I can tell, LADSPA v1.0
doesn't contain any provision for this. I think this means that LADSPA
v1.0 is incomplete - there is no way to smoothly upgrade/extend LADSPA
without breaking things.
I therefore propose that we add
int ladspa_version()
to the list of functions "required" to be exported by the plugin. if
its not present, we assume that its a LADSPA v1.0 plugin. if it is
present, it returns the version (MAJOR.MINOR) times 10. So, a v2.0
plugin will return 20, etc.
The LADSPA Control Protocol is more or less ready for use at this
time, and will enable people to write native GUIs using whatever
toolkit they want to control their own or other people's
plugins. Quick action on these items will mean we can move on to the
next phase of LADSPA's evolution.
--p
This archive was generated by hypermail 2b28 : Thu Dec 06 2001 - 16:13:25 EET