[LAD] [RFC] LADSPA 1.2

Krzysztof Foltman wdev at foltman.com
Fri Jun 19 18:00:50 UTC 2009


Fraser wrote:
> I'd be very happy to see this functionality too.
> This (for me) would allow the removal of just about all parameter conversions
> from the run function and just do them for display. (ie keep parameters native
> as I don't have to worry about exposing internal values to users anymore). It
> actually solves a whole lot of issues as we don't have to rely on hints to fine
> tune the display of parameters.
>   
Such a change could also give you problems if you expose 
implementation-defined values (as opposed to real-life-compatible units) 
to users. Think of backward compatibility, for example.
> While ideas are being tossed about, here are some more...
>   
Be careful: I can't speak for everyone, but after years of stagnation it 
would be nice to get a useful 1.2 out of the door without trying to cram 
every possible good idea into it.

On the other hand, I'm definitely going to push for more improvements. 
Just let's finalize 1.2 first, before everyone involved exceeds their 
quota of give-a-damn ;)

Some ideas about discovery (which I *wouldn't* like to put into v1.2):

1. Define a plugin exported function (or a set of those) that need to be 
called to notify the plugin about functionality it implements; which 
will affect the set of descriptors that ladspa_descriptor will return 
(i.e. host calls a plugin function called ladspa_host_version(1, 5); so 
that plugin knows to return the plugins that require LADSPA v1.5 to be 
implemented by the host)

This is actually dangerous in context of multiple hosts within same 
process, and contrary to intuition, this situation may happen (say, 
LADSPA plugins loaded into Ingen either directly or as LV2 via NASPRO 
wrapper; )

2. Provide a new discovery function (say, ladspa15_descriptor), with 
additional parameters that pass at least the version number implemented 
by the host, and maybe some callback mechanism that can be used to 
obtain information about the host.

Or alternatively, we can use some sort of RDF-based discovery mechanism, 
preferably using some human-friendly notation. I've heard Turtle is 
rather nice from that point of view ;)
> Do you think it would be possible to give the plugins some mechanism to
> interrogate the host without breaking compatibility with ladspa v1.1? The things
> I'd like to be able to find out about a host is for example:
> * The current time signature and tempo (can be null when irrelevant)
>   
These may be control ports with special hints, or special name, or some 
transport related callback. It should be done reasonably soon, but it 
shouldn't be done in v1.2 IMHO.

(I want it for Vintage Delay and other things, too!)
> * The language of the users environment (since we can format the parameters now)
>   
The language can be read via getenv() - you may want to keep it simple :)

The host name - I wouldn't push for or against that.

Factory presets are important, too, but it proved to be a contentious 
issue more than one time already, and you probably don't want to wait 
until everyone agrees or stops giving a damn ;). If I had my way, I'd 
probably avoid RDF or even XML, but that's, again, a flamewar waiting to 
happen.

Krzysztof




More information about the Linux-audio-dev mailing list