Ooof. Quite a few good questions... Most of the answers boil down to
"because it keeps the API slim and compatible," but here's the full
discussion:
> * 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);
The existing instantiate() and cleanup() functions are intended to cover
all instantiation, initialisation, cleanup and deletion stages.
>* 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
In LADSPA port configuration is fixed at plugin type level and will not
vary for an instance. Yes, this is a compromise to keep the API slim and
compatible. Hopefully most real-world cases can be handled by including
multiple versions of the plugin in the same library anyway.
> how to disconnect ports? By passing a NULL buffer to connect_port()? By
a
> dedicated disconnect_port()? Needs to be documented anyway
Disconnecting ports is meaningless in LADSPA. Ports must be connected
before run() is called.
> * 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);
Not an option as specified - if you need to change sample rate you will
need to replace the instance you're using. This keeps the API slim. I don't
imagine many hosts will have a problem with this, but maybe I'm missing
something.
> * it would be nice to allow default values for input ports and not
*requiring*
> a connection if the port has a default
[...]
Broadly this isn't a bad idea although I slightly prefer the approach
suggested by Alexander Konig. However I'd still want connection to be
mandatory for simplicity and speed.
> 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
The host I've built is actually C++ too - I'll provide a generic class to
handle the library loading/linkage stage in C++ if people would like, but
beyond this I think C++ developers should be quite happy working with
LADSPA_Descriptor and LADSPA_Handle pointers. Doing anything else will just
result in an unnecessary function call overhead.
>* how about splitting run into
>
> void (*run_replacing) (...) and
> void (*run_adding) (...)
>
> as suggested in this mailing list
Very tempting, but I'd prefer to keep off this one to keep the API slim and
the demands on plugin developers as simple as possible.
> * (A very important) question: can VST1 be wrapped in LADSPA as of now?
Sounds worth checking - anyone have a copy of the spec to hand?
> The petty things: :)
>
>* LADSPA is not a very nice name to remember IMHO; I would suggest "BOSSA"
> since we already have (S)ALSA :-)
How about RRRSPAFAHETSP (really really really simple plugin api for all
hosts except the seriously pathological)...?
It's really not too bad: LAD (Linux Audio Developer) + SPA (Simple Plugin
API).
> * I would enforce GNU coding standards to be used, if I was to rule :)
> http://www.gnu.org/prep/standards.html
First thing PBD did to the API was completely rearrange it from my style to
his (admittedly I'd used a rather Windows-y approach) - personally I don't
care what style it's in. Does anyone else? I'm quite happy to convert to
GNU coding standards if people like.
>> 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?).
These are questions for future extension - at this stage a host will need
some way to identify the plugin type, in which case the API can be changed
in all sorts of ways. Using #define is too late for the host - at this
stage the shared object has already been built.
>> 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.
Fair point. Perhaps people should have a look at the proof-of-concept code
(includes three plugins and two hosts) at
http://www.muse.demon.co.uk/ladspa.html. I think we're at the stage where
it's worth people playing around with a few prototypes as hopefully not too
much will need to change. LADSPA was developed from looking at
architectures used by a number of existing packages and I'm confident about
it - I don't think I've missed too much (although the control range issue
is a good one - I'd not been thinking too much about the GUI...).
-- Richard
