[LAD] RFC: Default discovery paths for LADSPA, LRDF, LV2 and DSSI (and more?)

[David Robillard]

On Mon, 2009-07-06 at 11:05 +0100, Chris Cannam wrote:
> On Mon, Jul 6, 2009 at 5:01 AM, David Robillard<dave at drobilla.net> wrote:
> > There are conflicts with the unique ID too, but there's no accounting
> > for broken plugins I guess.
> 
> Filename/label can be made to work; "unique" ID can't, for any dynamic
> or automatically generated plugin library.
> 
> Take dssi-vst for example.  It consists of a single library that
> publishes many LADSPA plugins, whose number and type are unknown until
> run time.  It can't map them onto a reserved range because it doesn't
> know in advance what plugins it may have to wrap.  It can't
> realistically generate a good hashed value, because of the range
> limitation given in the LADSPA header ("below 0x1000000") and the need
> to avoid reserved ranges.  It can't pass through the VST plugin's
> existing numerical ID, because these are typically generated by
> mapping from strings or hashing, and consequently are also usually out
> of range, and anyway it can't know whether a LADSPA plugin of the same
> ID already exists.

None of this makes the filename/label any less of a weak identifier in
the long-term.

It's an acceptable identifier only at runtime, on a single system, while
the plugin is loaded.  Certainly not in save files.

Should LADSPA have used a better ID?  Yes.
Did it?  No.
Is soname:label an ID for a given plugin?  No.

> Never rely on the "unique" ID of a LADSPA plugin.

Never rely on the soname/label either.

> (URIs are far better than either filename/label or numerical ID of course.)

Bingo.

If people are seriously considering a new ladspa revision, this is
something that should actually be taken care of.  Far more important
than what got that ball rolling in the first place...

-dr