On Mon, 2009-07-06 at 11:05 +0100, Chris Cannam wrote: > On Mon, Jul 6, 2009 at 5:01 AM, David Robillard<[email protected]> 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 _______________________________________________ Linux-audio-dev mailing list [email protected] http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
