18 Apr
2011
18 Apr
'11
7:30 p.m.
On Mon, 2011-04-18 at 17:09 +0200, Stefano D'Angelo wrote:
2011/4/18 David Robillard <d(a)drobilla.net>et>:
"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
On Sun, 2011-04-17 at 19:16 +0100, Chris Cannam
wrote:
/* 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). On 17 April 2011 18:12, David Robillard
<d(a)drobilla.net> wrote:
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... 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).