Subject: Re: [linux-audio-dev] New LADSPA Version - Issues Resolved?
From: Jarno Seppanen (jams_AT_cs.tut.fi)
Date: to maalis 09 2000 - 07:09:03 EST
"Richard W.E. Furse" <richard_AT_muse.demon.co.uk> writes:
> New version of the LADSPA API and example plugins/hosts available at
> http://www.muse.demon.co.uk/ladspa.html. Plugins-per-library issues are
Well, here's some issues for discussion off the top of my head:
* init and destructor functions missing from the plugin lifecycle
"ctor-init-run-run-...-cleanup-init-run-run-...-cleanup-dtor"
void (*initialize)(LADSPA_Handle Instance);
void (*destruct)(LADSPA_Handle Instance);
* at what points are ports created/destroyed in the above lifecycle? At
construction I would believe? Having a member variable for port descriptors
and names implies
(a) either changing the arrays (creating/destroying ports) must be forbidden or
(b) the host has to poll for changes.
examples speaking for allowing port creation/destroyal:
* an adder plugin
* a multiplexer or a demultiplexer plugin
* a compressor/expander which can be run in mono and linked-stereo modes
* how to disconnect ports? By passing a NULL buffer to connect_port()? By a
dedicated disconnect_port()? Needs to be documented anyway
* how to change sample rate after construction? I would take the sample rate
parameter out of the ctor and provide the following pair instead:
void set_sample_rate (LADSPA_Handle Instance, unsigned long sample_rate);
unsigned long get_sample_rate (LADSPA_Handle Instance);
* it would be nice to allow default values for input ports and not *requiring*
a connection if the port has a default
bool have_port_default (LADSPA_Handle Instance, unsigned long port);
void set_port_default (LADSPA_Handle Instance, unsigned long port,
LADSPA_Data default_value);
LADSPA_Data get_port_default (...);
the input ports which don't have a default value are *required* (by the
host) to have a connection
* as well as a standard C interface, a standard C++ wrapper should be included
in LADSPA; there are quite a number of C++ developers in the music field
* how about splitting run into
void (*run_replacing) (...) and
void (*run_adding) (...)
as suggested in this mailing list
* (A very important) question: can VST1 be wrapped in LADSPA as of now?
The petty things: :)
* LADSPA is not a very nice name to remember IMHO; I would suggest "BOSSA"
since we already have (S)ALSA :-)
* I would enforce GNU coding standards to be used, if I was to rule :)
http://www.gnu.org/prep/standards.html
> I think this version meets basic requirements for a simple plugin API. It
> still only supports float types, but I think that's sensible at this level.
I am fully behind having only a float datatype. Only there should be a
#define LADSPA_DATA_FLOAT or something, in order to be able to use proper math
functions. Also it should be discussed what LADSPA_Data can be changed to
(surely doubles, but what else?).
> If (*IF*) it's alright as it stands I suggest we ruminate on it for a week
> or two and then formalise it. That's subject to anything popping up from
> Steinberg of course...
I would suggest not to "standardize" the API before it has been found useful
and effective in (prototype) applications. I would guess that there ARE still
issues which will only pop out when starting to use the interface and write
programs for it.
In other words, let the brave guys start to use LADSPA and then feed their
improvements back to the API.
-- -Jarno
This archive was generated by hypermail 2b28 : su maalis 12 2000 - 09:14:05 EST