6 Jul
2009
6 Jul
'09
8:27 p.m.
On Mon, 2009-07-06 at 11:05 +0100, Chris Cannam wrote:
On Mon, Jul 6, 2009 at 5:01 AM, David
Robillard<dave(a)drobilla.net> wrote:
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.
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. 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