[linux-audio-dev] LADSPA "Unique" IDs

[Chris Cannam]

On Thursday 29 Jul 2004 12:42 am, Dave Robillard wrote:
> I vaguely remember a discussion here about LADSPA ID's (unsigned
> long UniqueID) not actually being globally unique to a plugin like
> the header implies, but I can't find it in the archives.
>
> So.. unique or not?  Basically I need to know what the "proper"
> information is to send a synth in order to load a plugin.

The outcome was that (i) LADSPA _does_ appear to specify that the 
unique ID should be globally unique, but (ii) it's not in practice 
easy to guarantee that, for generated or wrapper plugins (e.g. a vst 
wrapper that doesn't know how many plugins will be in the .so until 
it's counted your VSTs), and (iii) some plugin developers (Steve!) 
thought the LADSPA docs said differently anyway, so it's possible 
they may have made plugins with duplicate IDs.

This means IMHO it's a bad idea to rely on unique ID to be actually 
unique.  Some hosts (including jack-rack and Rosegarden up to 0.9.8 
and, well, for all I know every other LADSPA host out there) do so 
anyway, so you might find that convincing enough.  Since 0.9.8 I've 
switched Rosegarden over to using the filename and plugin label.  
(Actually RG uses a string "<plugin type>:<path>:<label>", e.g. 
ladspa:/usr/local/lib/ladspa/tap_echo.so:tap_stereo_echo or dssi:/
usr/local/lib/dssi/xsynth-dssi.so:Xsynth -- full path for the 
filename, and if that isn't found I revert to the first file of that 
name in the LADSPA path.)

The comment for label in ladspa.h says:

  /* This identifier can be used as a unique, case-sensitive
     identifier for the plugin type within the plugin file. Plugin
     types should be identified by file and label rather than by index
     or plugin name, which may be changed in new plugin
     versions. Labels must not contain white-space characters. */

To me this makes it pretty plain that filename and label is at least 
intended to be a valid unique ID within your filesystem, and in 
practice I'd expect it to be an effective id for the plugin anywhere 
in the world. 

One problem is that there seems to be an informal understanding that 
if you change the port specifications for a plugin you should also 
change its unique ID, but I don't think there's any such 
understanding for labels, so you don't have the reassurance of 
knowing you're using the version you actually intended.

> At the moment I'm sending filename and index

I think index is bad -- again, consider your VST wrapper .so with 
potentially different numbers of plugins every time you run it.


Chris