[linux-audio-dev] LADSPA Issues

Chris Cannam cannam at all-day-breakfast.com
Wed May 18 09:16:43 UTC 2005

On Wednesday 18 May 2005 09:56, Dave Robillard wrote:
> So why wasn't the unique ID the thing to use?

Because it's impossible to find any way to guarantee it's actually 
unique, for example in the case of a wrapper plugin that generates 
plugins on the fly.  ladspa-vst / dssi-vst are obvious real-world 
examples.  (DSSI deprecates the LADSPA "unique" ID for this reason -- 
there are a few paragraphs about it in the current DSSI RFC.)

And of course having to have a central body to issue IDs is painful: 
that's why most identification schemes these days use texts drawn from 
a pre-existing common pool, such as URIs for schema IDs.

Many (possibly most) LADSPA hosts actually do use the "unique" ID to 
identify plugins.  They will break badly when faced with generated 
plugins like these.

The right thing to do is just make sure the .so name doesn't change.  
After all, other dynamic libraries are always referred to by .so name 
and nobody ever complains about that -- would you expect a packager to 
get away with renaming libxml.so to libextensiblemarkuplanguage.so 
without breaking anything?  It's not seen as a problem for plugins on 
other platforms, either.

There are still potential complications if a plugin library is installed 
more than once, but at least the user can be aware of them -- whereas a 
changing or conflicting unique ID might be impossible for the user to 
work around (or even to know about).  And at least the problem (for the 
admin) of managing plugin libraries becomes the same as managing any 
other sort of library, rather than having to manage potential conflicts 
of IDs buried deep within the binary.


More information about the Linux-audio-dev mailing list