On Tue, 7 Jul 2009 10:10:24 +0100 Chris Cannam <[email protected]> wrote:
> On Mon, Jul 6, 2009 at 11:27 PM, David Robillard<[email protected]> > 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 _______________________________________________ Linux-audio-dev mailing list [email protected] http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
