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