28 Jul
2004
28 Jul
'04
9:57 p.m.
I vaguely remember a discussion here about LADSPA ID's (unsigned long
UniqueID) not actually being globally unique to a plugin like the header
implies, but I can't find it in the archives.
So.. unique or not? Basically I need to know what the "proper"
information is to send a synth in order to load a plugin. At the moment
I'm sending filename and index, which I don't think is ideal. (The
synth could be running on a completely seperate machine, so the sender
and receiver might not have the same LADSPA plugins around...)
Thanks,
-DR-
29 Jul
29 Jul
6:01 a.m.
On Thursday 29 Jul 2004 12:42 am, Dave Robillard wrote:
I vaguely remember a discussion here about LADSPA
ID's (unsigned
long UniqueID) not actually being globally unique to a plugin like
the header implies, but I can't find it in the archives.
So.. unique or not? Basically I need to know what the "proper"
information is to send a synth in order to load a plugin.
The outcome was that (i) LADSPA _does_ appear to specify that the
unique ID should be globally unique, but (ii) it's not in practice
easy to guarantee that, for generated or wrapper plugins (e.g. a vst
wrapper that doesn't know how many plugins will be in the .so until
it's counted your VSTs), and (iii) some plugin developers (Steve!)
thought the LADSPA docs said differently anyway, so it's possible
they may have made plugins with duplicate IDs.
This means IMHO it's a bad idea to rely on unique ID to be actually
unique. Some hosts (including jack-rack and Rosegarden up to 0.9.8
and, well, for all I know every other LADSPA host out there) do so
anyway, so you might find that convincing enough. Since 0.9.8 I've
switched Rosegarden over to using the filename and plugin label.
(Actually RG uses a string "<plugin type>:<path>:<label>",
e.g.
ladspa:/usr/local/lib/ladspa/tap_echo.so:tap_stereo_echo or dssi:/
usr/local/lib/dssi/xsynth-dssi.so:Xsynth -- full path for the
filename, and if that isn't found I revert to the first file of that
name in the LADSPA path.)
The comment for label in ladspa.h says:
/* 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. */
To me this makes it pretty plain that filename and label is at least
intended to be a valid unique ID within your filesystem, and in
practice I'd expect it to be an effective id for the plugin anywhere
in the world.
One problem is that there seems to be an informal understanding that
if you change the port specifications for a plugin you should also
change its unique ID, but I don't think there's any such
understanding for labels, so you don't have the reassurance of
knowing you're using the version you actually intended.
At the moment I'm sending filename and index
I think index is bad -- again, consider your VST wrapper .so with
potentially different numbers of plugins every time you run it.
Chris
6:15 a.m.
On Thu, Jul 29, 2004 at 09:17:03AM +0100, Chris Cannam wrote:
On Thursday 29 Jul 2004 12:42 am, Dave Robillard
wrote:
Personally I've only done that by accident! But it has happened. My buil
process now has a bozosity checker run, that looks for silly mistakes,
like two plugins with the same ID. I do learn eventually :)
I vaguely remember a discussion here about LADSPA
ID's (unsigned
long UniqueID) not actually being globally unique to a plugin like
the header implies, but I can't find it in the archives.
So.. unique or not? Basically I need to know what the "proper"
information is to send a synth in order to load a plugin.
The outcome was that (i) LADSPA _does_ appear to specify that the
unique ID should be globally unique, but (ii) it's not in practice
easy to guarantee that, for generated or wrapper plugins (e.g. a vst
wrapper that doesn't know how many plugins will be in the .so until
it's counted your VSTs), and (iii) some plugin developers (Steve!)
thought the LADSPA docs said differently anyway, so it's possible
they may have made plugins with duplicate IDs. /* 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. */
To me this makes it pretty plain that filename and label is at least
intended to be a valid unique ID within your filesystem, and in
practice I'd expect it to be an effective id for the plugin anywhere
in the world.
I think it should be: local filenames are unique, and labels are
required to be unique in the file.
A problems with using UIDs for this kind of thing is that they dont have
to change with plugin versions, so you can end up with two plugins iwth
the same ID and ports, but different paths nad different effects/bugs, and
you dont know which one to load.
One problem is that there seems to be an informal
understanding that
if you change the port specifications for a plugin you should also
change its unique ID, but I don't think there's any such
understanding for labels, so you don't have the reassurance of
knowing you're using the version you actually intended.
All this and more :)
- Steve
6:20 a.m.
On Thursday 29 Jul 2004 9:00 am, Steve Harris wrote:
On Thu, Jul 29, 2004 at 09:17:03AM +0100, Chris Cannam
wrote:
Is that different from what I said?
Chris
/* 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. */
To me this makes it pretty plain that filename and label is at
least intended to be a valid unique ID within your filesystem,
and in practice I'd expect it to be an effective id for the
plugin anywhere in the world.
I think it should be: local filenames are unique, and labels are
required to be unique in the file.
7:52 a.m.
On Thu, Jul 29, 2004 at 09:36:41 +0100, Chris Cannam wrote:
On Thursday 29 Jul 2004 9:00 am, Steve Harris wrote:
No, sorry, pre-coffee abiguous grammar, I wasn't correcting you, I meant:
I think it should be, *because* local filenames are unique, and labels are
required to be unique in the file.
But it was also a pretty pointless comment. Sorry.
/me gets coffee
- Steve
On Thu, Jul 29, 2004 at 09:17:03AM +0100, Chris
Cannam wrote:
Is that different from what I said? /* 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. */
To me this makes it pretty plain that filename and label is at
least intended to be a valid unique ID within your filesystem,
and in practice I'd expect it to be an effective id for the
plugin anywhere in the world.
I think it should be: local filenames are unique, and labels are
required to be unique in the file.
7413
days inactive
7414
days old
linux-audio-dev@lists.linuxaudio.org
4 comments
3 participants
participants (3)
-
Chris Cannam -
Dave Robillard -
Steve Harris