[linux-audio-dev] LADSPA Issues
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
> 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