22 Apr
2006
22 Apr
'06
10:27 a.m.
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