Re: [LAD] [RFC] LADSPA 1.2

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

_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Received on Sat Jun 20 00:15:02 2009