Re: [linux-audio-dev] LADSPA 2

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
Received on Sun Apr 23 00:15:07 2006