Re: [LAD] [ann] CAPS 0.4.5

From: David Robillard <d@email-addr-hidden>
Date: Mon Apr 18 2011 - 20:30:32 EEST

On Mon, 2011-04-18 at 17:09 +0200, Stefano D'Angelo wrote:
> 2011/4/18 David Robillard <d@email-addr-hidden>:
> > On Sun, 2011-04-17 at 19:16 +0100, Chris Cannam wrote:
> >> On 17 April 2011 18:12, David Robillard <d@email-addr-hidden> wrote:
> >> > On Thu, 2011-04-14 at 11:59 +0100, Chris Cannam wrote:
> >> >> I like to disagree with David on most things LADSPA -- for example I
> >> >> think a host that uses the "unique" ID at all is broken from the
> >> >> outset
> >> >
> >> > Well, that's just silly... it's the only ID there is. What else would
> >> > they use?
> >>
> >> Library name plus label, for example. My hosts do that and have done
> >> for years. Not ideal either of course, but at least it doesn't
> >> completely stuff up any situation where a numerical ID can't be
> >> generated in advance (dssi-vst, etc).
> >
> > That is not guaranteed to be unique, and I know of at least one case in
> > practise where it isn't (various blop packages have a different library
> > name). There's no reason whatsoever the library name and label of
> > various LADSPA plugin distributions can't be completely different,
> > neither one is an ID.
> >
> > Of course, the numeric IDs are screwed up for a few plugins in reality
> > as well, but at least that is actually defined to be an ID (therefore
> > those plugins are broken).
> >
> > Perhaps the LADSPA spec /should/ use that (or whatever else) as an
> > identifier, but it doesn't. It is an extremely bad idea to pretend a
> > spec says what you wish it did and implement that instead of what the
> > spec actually says.
> >
> > I know because I blindly heeded this advice in the past, and it screwed
> > me :). Please don't advise people that this is what a LADSPA
> > implementation should do...
>
> /* This identifier can be used as a unique, case-sensitive
> identifier for the plugin type within the plugin file. Plugin
> types should be identified by file and label rather than by index
> or plugin name, which may be changed in new plugin
> versions. Labels must not contain white-space characters. */
> const char * Label;
>
> I would say Chris is right here... but since I don't care about LADSPA
> hosts, and only about LADSPA plugins bridged to LV2, for our purposes
> UniqueID is fine (bridging bridged plugins is not of interest to me).

"within the plugin file"

Nothing says the plugin file name is meaningful in any way, or globally
unique. Ironically bridges and plugin generators and such, the case
mentioned as a rationalization for this, is one case where it wouldn't
be.

file name + label would be a really annoying two-piece identifier
anyway, even if it was an actual global identifer.

The LADSPA spec is pretty broken in this respect, if that pair of quasi
identifiers is the global identifier then why would there be a UniqueID
in the first place?

-dr

_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-dev
Received on Tue Apr 19 00:15:01 2011

This archive was generated by hypermail 2.1.8 : Tue Apr 19 2011 - 00:15:01 EEST