[LAD] RFC: Default discovery paths for LADSPA, LRDF, LV2 and DSSI (and more?)

[hollunder at gmx.at]

On Tue, 7 Jul 2009 10:10:24 +0100
Chris Cannam <cannam at all-day-breakfast.com> wrote:

> On Mon, Jul 6, 2009 at 11:27 PM, David Robillard<dave at drobilla.net>
> wrote:
> > None of this makes the filename/label any less of a weak identifier
> > in the long-term.
> >
> > It's an acceptable identifier only at runtime, on a single system,
> > while the plugin is loaded.  Certainly not in save files.
> 
> It's tolerable in principle and it works in practice, which is not
> especially good but better than the alternative.
> 
> We have a choice of two methods, both mandated by the header (airy
> declarations to the contrary notwithstanding).  One of them (numerical
> ID) works most of the time but fails irrecoverably in several
> real-world situations as of now, with no fix or workaround available
> to the host.  The other (filename/label) works most of the time and
> can be fudged by the host in most cases where it does fail.  Both of
> those are pretty lousy -- we agree on that -- but the numerical ID is
> clearly worse.  Hosts using the numerical ID will probably be loading
> the wrong plugins for some users' projects out there right now.
> 
> The main inadequacy of filename/label is a shortage of specification
> -- if it was clear that the label must change when the plugin changed
> (i.e. whenever you would also assume that the numerical ID should
> change), and that the soname was part of the identity of a plugin,
> then it would work fine all the time.
> 
> 
> Chris

Changing the ID with every plugin change seems ridiculous, especially
if you have to wait an unknown amount of time until you get an id.

"- I'm still waiting on a unique ID from the LADSPA people, and so the
LADSPA unique ID needs to be changed. Right now it's set to 1000."
http://web.mit.edu/tbaran/www/autotalent.html