22 Apr
2006
22 Apr
'06
2:31 p.m.
On Sat, Apr 22, 2006 at 02:26:57PM +0200, Thorsten Wilms wrote:
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 ;)
*gulp* ;)
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).
So... that is one thing that using RDF/web tech /can/ give you. eg. the
URI for the example plugin is http://plugin.org.uk/swh-plugins/amp/ if you
dereference that (ie. click on it ;) you will see some docs, but if you
use HTTP content negotiation and ask for it in Trutle you will get the RDF
description back, which /could/ have a machine readable bit telling you
where to get the package.
In combination with bundles that gives you the possibility to install
individual plugins.
It's a little bit sci-fi, but hopeful you can see that it's not too far
off.
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?
It would be 100% opposed to that. Plugins that crash when given odd values
are buggy (spec says they mustn't), and should be fixed. Use demolition,
report bugs.
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).
I might consider that for the future, but not for 2.0. I think its
important to get a more capable platform, before adding features.
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.
This has been propsed using labels, eg "OSC 1/frequency" and "OSC
1/amplitude", that's an informal part of the spec IIRC. You could encode
it in RDF if you wanted to:
[ # port defintion
ladspa:index 1 ;
ladspa:label "frequency" ;
ladspa:inGroup <groupO1>
] , [
ladspa:index 1 ;
ladspa:label "frequency" ;
ladspa:inGroup <groupO1>
] .
<groupO1> ladspa:label "OSC 1" .
But I dint think it offers much more.
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).
Ugh. Maybe sometime in the future. That sounds hard to use. c.f. 2.0
plans.
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 ;)
Plugins have URIs! And ports have uniqe identifying numbers within the
plugin. We could assign URIs to ports too, but I think thats going too
far.
Hints:
Maybe I just didn't see it, but shouldn't there be a hint for lists?
Like for plugins that have modes/presets?
Yes, there is, but I didnt show it in that example as the simple amp
doesnt need it. It looks like:
# ... inside port defn
ladspa:scalePoint [
ladspa:label "sine" ;
ladspa:value 0.0 .
], [
ladspa:label "square" ;
ladspa:value 1.0 .
], [
ladspa:label "saw" ;
ladspa:value 2.0 .
]
Presets:
Cross-host preset loading/saving.
Right, there are some obvious ways to do it. Later.
Help / Discription:
A way to bring up a short discription of a plugin and what the
ports are about.
Just dereference the plugin URI as text/html or text/plain.
MIDI/OSC
Don't know if the new LADSPAs should be able to handle MIDI/OSC,
but there should be plugins that do it ;)
DSSI. If this gets momentum retorfitting LADSPA 2 to DSSI will be easy. It
was designed with that in mind.
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.
Nope. Too hard, use the DSSI protocol.
- Steve