[linux-audio-dev] LADSPA Issues

Dave Robillard drobilla at connect.carleton.ca
Wed May 18 17:19:50 UTC 2005

On Wed, 2005-18-05 at 10:16 +0100, Chris Cannam wrote:
> 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.

Agreed, but as an app developer it's a bit frustrating to have "fix your
distribution" as the only answer when someone complains their patches
don't load.

> There are still potential complications if a plugin library is installed 
> more than once, but at least the user can be aware of them

Yes, vcf and blepvco both do this IIRC, and need to be fixed.

> -- 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.

Fair enough, these sounds like good enough reasons for me.  I guess
package maintainers just need to stop doing stupid things with library

(I still think the central repository is a good idea anyway, FWIW)


More information about the Linux-audio-dev mailing list