Re: [linux-audio-dev] LADSPA 2

From: Thorsten Wilms <t_w_@email-addr-hidden>
Date: Sat Apr 22 2006 - 15:26:57 EEST

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
Received on Sat Apr 22 16:15:13 2006

This archive was generated by hypermail 2.1.8 : Sat Apr 22 2006 - 16:15:13 EEST