On Thu, Jan 15, 2004 at 11:04:00 +0100, Alfons Adriaensen wrote:
Coming back to my original example, if you want a
plugin to create its own
GUI without any assistance from the host (and that is ATM the only option with
LADSPA) it *has* to know this, unless you want e.g. 16 or 32 identical
windows, one for each voice.
It's not really possible for the plugin to create a UI independently, the
UI control has to be routed via to host to allow automation.
I prefer a model when the host is reponsible for requesting the UI
creation, the UI talks to the host (eg. via OSC) and the host relays the
changes, via th LADSPA API to the plugin.
Agreed, but to
be acceptable it probably needs to be transparent to the
plugin if it doesnt want to know - obvious solutions such as setting
buffers to NULL if thier disconnected are a bit awkward to use.
And that's a pity. Since all ports in LADSPA are pointers, even if they
only carry a single value for each call to the process fuction, setting
the pointer to NULL would have been the obvious way to signal an unconnected
port. But it's too late now to do adopt this obvious convention.
Obvious, but highly inconvienient for plugin authors. It means you have to
check for the connected state of every input and have some kind of
fallback plan for when its not connected.
Say I have a 2->1 mixer plugin (trivial example). I have to check wether
input 1 and/or input 2 is connected and either have 4 different inner
loops, or alias some of the input buffers to be static zero buffers.
Providing a check algorithm of some kind and requireing the host to always
provide valid LADSPA input buffers is much more convienient.
[metadata streams]
You haven't given an exaple of where user-transparent metadata streams are
needed, but AFAIK none of the existing s/w modular systems use anything
like that.
My conclusion at this point is that ATM the scope of
LADSPA is too limited to be able
to say 'Module == LADSPA Plugin', even if we ignore the GUI aspect. This is not
meant as
criticism on LADSPA, it's just a fact, and as the 'S' implies, probably by
design.
Sure, but equally modular synth modules are also very simple - at least
externally. The only thing they can do that LADSPA can't is: have UIs and
detect wether thier inputs are connected. Those are not hard problems to
solve.
FWIW, I dont think its neccesarily important that LADSPA is used in
modular synths, its far more important that modular synths all use the
same module format, whatever it is, to save the duplication of effort
thats going on currently.
- Steve