[linux-audio-dev] LADSPA 2

Thorsten Wilms t_w_ at freenet.de
Sat Apr 22 12:26:57 UTC 2006


On Sat, Apr 22, 2006 at 10:53:58AM +0100, Steve Harris wrote:
> Almost two years ago at the LA conference a bunch of us agreed that
> something need to be done to improve LADSPA, and on the approximate
> direction it should take.


I'm not competent to comment on header files or implementation details.
But via Om, I'm a LADSPA power user and would like to bring up 
some issues ;)


Distribution / finding plugins:
I would like to have an app, where I can put checkmarks to all plugins 
and they will be fetched and installed (buidling from source / binaries
as option).
But just a way to get from the host not finding a plugin to the name 
of the collection it's in would be nice already (so an app like Om can 
not only say plugin-x not found, but also point to the package).


Stability:
There are some plugins that will die if fed with values out of their 
range (and this happens easily in a modular system). Maybe some mechanism 
to protect against this could be build into the framework?


Control/audio rate:
Having several variations of the same plugin to allow varying audio/ 
control rate port setups makes for unnecessary long plugin lists and 
requires the user to delete and insert a different one, should he find 
out some port should be audio, not control rate. Just look at the  
sine oscillator(s) ...
The rate of a port should be switchable (at leat in all cases where 
we have both versions now).


Port grouping:
Hosts should be able to see, wether 2 ports are independent, or happen 
to be a stereo pair (or any multi-channel setup).
Also a way to specify that things like frequency and amount ports of 
an EQ form pairs might be nice. Should be helpful for generative plugin
GUIs.


Port Roles:
Ports could have roles assigned to them, like signal_input, sidechain, 
latency or bpm (the last for transport awareness and to make it possible 
hosts assign values to it automaticaly).


Referencing:
There needs to be a safe way to reference plugins and their ports. 
Portnames make for human readable patch files, but this doesn't 
work with i18n, when Attack becomes Einschwingzeit ;)


Hints:
Maybe I just didn't see it, but shouldn't there be a hint for lists?
Like for plugins that have modes/presets?


Presets:
Cross-host preset loading/saving.


Help / Discription:
A way to bring up a short discription of a plugin and what the 
ports are about.


MIDI/OSC
Don't know if the new LADSPAs should be able to handle MIDI/OSC, 
but there should be plugins that do it ;)


GUI lib:
There could be 1 or 2 (GTK, QT) libs for generative plugin GUIs, 
for hosts not having to reinvent the wheel and for consistency.


---
Thorsten Wilms



More information about the Linux-audio-dev mailing list