linuxaudio.org

Fraser wrote:

quoted text
> 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.

quoted text
> 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 ;)

quoted text
> 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!)

quoted text
> * 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@lists.linuxaudio.org

http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev