18 May
2005
18 May
'05
6:58 a.m.
Hi all,
A while ago I started a thread about the proper way to refer to LADSPA
plugins (in save files or whatever) and the consensus was library
filename + label.
People have been having problems with library name - different packages
seem to make different names for the libraries (prefixing blop_, for
example) so it doesn't always work. Basically I think using shared
library file name is an awful way to reference plugins for numerous
reasons.
So why wasn't the unique ID the thing to use? There is a unique plugin
ID in LADSPA, if not for this then for what reason?
In a similar vein, I really think the current system for LADSPA
distribution sucks - big tarballs from various devs containing heaps of
completely unrelated plugins. A centralized site where plugins can be
submitted on their own (or in related groups) would be a great thing,
IMO, and would make it easy to verify that unique IDs are in fact unique
to solve the above problem.
Right now if a developer wants to make just one random plugin, they
don't really have a sane way of getting it out there. I'm willing to
full-time maintain the site, but I don't really have the
hosting/abilities to create it. What do the other plugin authors think
about this? Is there a web nerd around with the
time/hosting/inclination to build the site? It doesn't need to be
fancy, just functional.
Cheers,
-DR-
18 May
18 May
7:15 a.m.
On Wednesday 18 May 2005 09:56, Dave Robillard wrote:
So why wasn't the unique ID the thing to use?
Because it's impossible to find any way to guarantee it's actually
unique, for example in the case of a wrapper plugin that generates
plugins on the fly. ladspa-vst / dssi-vst are obvious real-world
examples. (DSSI deprecates the LADSPA "unique" ID for this reason --
there are a few paragraphs about it in the current DSSI RFC.)
And of course having to have a central body to issue IDs is painful:
that's why most identification schemes these days use texts drawn from
a pre-existing common pool, such as URIs for schema IDs.
Many (possibly most) LADSPA hosts actually do use the "unique" ID to
identify plugins. They will break badly when faced with generated
plugins like these.
The right thing to do is just make sure the .so name doesn't change.
After all, other dynamic libraries are always referred to by .so name
and nobody ever complains about that -- would you expect a packager to
get away with renaming libxml.so to libextensiblemarkuplanguage.so
without breaking anything? It's not seen as a problem for plugins on
other platforms, either.
There are still potential complications if a plugin library is installed
more than once, but at least the user can be aware of them -- whereas a
changing or conflicting unique ID might be impossible for the user to
work around (or even to know about). And at least the problem (for the
admin) of managing plugin libraries becomes the same as managing any
other sort of library, rather than having to manage potential conflicts
of IDs buried deep within the binary.
Chris
3:22 p.m.
On Wed, 2005-18-05 at 10:16 +0100, Chris Cannam wrote:
On Wednesday 18 May 2005 09:56, Dave Robillard wrote:
Agreed, but as an app developer it's a bit frustrating to have "fix your
distribution" as the only answer when someone complains their patches
don't load.
So why wasn't the unique ID the thing to use?
Because it's impossible to find any way to guarantee it's actually
unique, for example in the case of a wrapper plugin that generates
plugins on the fly. ladspa-vst / dssi-vst are obvious real-world
examples. (DSSI deprecates the LADSPA "unique" ID for this reason --
there are a few paragraphs about it in the current DSSI RFC.)
And of course having to have a central body to issue IDs is painful:
that's why most identification schemes these days use texts drawn from
a pre-existing common pool, such as URIs for schema IDs.
Many (possibly most) LADSPA hosts actually do use the "unique" ID to
identify plugins. They will break badly when faced with generated
plugins like these.
The right thing to do is just make sure the .so name doesn't change.
After all, other dynamic libraries are always referred to by .so name
and nobody ever complains about that -- would you expect a packager to
get away with renaming libxml.so to libextensiblemarkuplanguage.so
without breaking anything? It's not seen as a problem for plugins on
other platforms, either. There are still potential complications if a plugin
library is installed
more than once, but at least the user can be aware of them
Yes, vcf and blepvco both do this IIRC, and need to be fixed.
-- whereas a
changing or conflicting unique ID might be impossible for the user to
work around (or even to know about). And at least the problem (for the
admin) of managing plugin libraries becomes the same as managing any
other sort of library, rather than having to manage potential conflicts
of IDs buried deep within the binary.
Fair enough, these sounds like good enough reasons for me. I guess
package maintainers just need to stop doing stupid things with library
names.
(I still think the central repository is a good idea anyway, FWIW)
-DR-
8:03 a.m.
On Thu, May 19, 2005 at 03:19:50 +1000, Dave Robillard
wrote:
In the commercial world (of one application I develop for anyway) a number
of unique plugin ids are allocated per developer licence of a piece of
host software. There are also some that are published but never allocated,
and kept free for other development purposes.
In practise, everyone randomly uses id's that don't cause problems - or
uses the ones from some company they worked for a few years ago (this is
mostly for internal use)
It's chaos in other words, so it's probably not the model to follow :)
dave
(I still think the central repository is a good
idea anyway, FWIW)
So do I, but its a hell of a lot of effort, and its unlikly to be kept
up to date. 
10:31 a.m.
On Fri, 2005-05-20 at 11:03 +0100, Dave Griffiths wrote:
A heirarchical ID system - a bit like OIDs in SNMP - might be worth
considering. The IDs form a tree rather than a flat space, and once you
own an ID node in the tree (like in SNMP when you are allocated an
"enterprise" OID) then you own every node beneath that node in the tree.
So, assuming an ID were a sequence of bytes...
Whoever owns the ID 255.24.24.123 owns every longer ID beginning with
this sequence. If you allow them to reassign their sub-IDs to other
developers, then ANYBODY (who already has an ID) becomes an authority
who can issue further IDs.
A central authority is required to seed the tree by issuing the first
top level IDs... but even if this authority ceases to function after
some time, an ID (and the infinity of IDs beneath that ID) is always
available so long as somebody who already has one is willing to issue
one.
And there doesn't need to be an up-to-date totally complete list of IDs
available. A plugin collection, for example, can be distributed along
with a description of just its own part of the ID space. Again this is
like SNMP: You don't need a single super-MIB describing every enterprise
OID that any manufacturer has ever allocated, you just need the various
individual MIBs to describe the kit you've actually got, which apps can
merge into a single tree of all the locally known IDs.
-- Simon Jenkins
On Thu, May
19, 2005 at 03:19:50 +1000, Dave Robillard wrote:
In the commercial world (of one application I develop for anyway) a number
of unique plugin ids are allocated per developer licence of a piece of
host software. There are also some that are published but never allocated,
and kept free for other development purposes.
In practise, everyone randomly uses id's that don't cause problems - or
uses the ones from some company they worked for a few years ago (this is
mostly for internal use)
It's chaos in other words, so it's probably not the model to follow :)
(I still think the central repository is a good
idea anyway, FWIW)
So do I, but its a hell of a lot of effort, and its unlikly to be kept
up to date. 
11:19 a.m.
On Fri, May 20, 2005 at 01:31:16 +0100, Simon Jenkins wrote:
On Fri, 2005-05-20 at 11:03 +0100, Dave Griffiths
wrote:
A heirarchical ID system - a bit like OIDs in SNMP - might be worth
considering. The IDs form a tree rather than a flat space, and once you
own an ID node in the tree (like in SNMP when you are allocated an
"enterprise" OID) then you own every node beneath that node in the tree.
Or, we could use a system thats been demonstrated to work really well...
http://www.w3.org/Addressing/
- Steve
On Thu,
May 19, 2005 at 03:19:50 +1000, Dave Robillard wrote:
In the commercial world (of one application I develop for anyway) a number
of unique plugin ids are allocated per developer licence of a piece of
host software. There are also some that are published but never allocated,
and kept free for other development purposes.
In practise, everyone randomly uses id's that don't cause problems - or
uses the ones from some company they worked for a few years ago (this is
mostly for internal use)
It's chaos in other words, so it's probably not the model to follow :)
(I still think the central repository is a good
idea anyway, FWIW)
So do I, but its a hell of a lot of effort, and its unlikly to be kept
up to date. 
23 May
23 May
1:03 p.m.
Good idea.
reverse - domain name type addresses are used quite widely now, in Java
for example and in all apple's latest stuff.
eg "uk.org.plugin.analogueOsc"
combined with a version number, you can correctly identify plugins no
matter their filename..
-n
On 20 May 2005, at 14:19, Steve Harris wrote:
Or, we could use a system thats been demonstrated to
work really
well...
http://www.w3.org/Addressing/
25 May
25 May
5:16 a.m.
On Mon, 2005-05-23 at 16:03 +0100, Nick Dowell wrote:
Good idea.
reverse - domain name type addresses are used quite widely now, in Java
for example and in all apple's latest stuff.
eg "uk.org.plugin.analogueOsc"
Can we have a unique divider between the domain and product?
foo.bar(a)example.com
and
foo(a)bar.example.com
.. are in java both represented as
com.example.bar.foo
Having instead, say
com.example(a)bar.foo
and
com.example.bar@foo
.. would resolve this (minor) issue.
combined with a version number, you can correctly
identify plugins no
matter their filename..
-n
On 20 May 2005, at 14:19, Steve Harris wrote:
--
Or, we could use a system thats been demonstrated
to work really
well...
http://www.w3.org/Addressing/
18 May
18 May
8:17 p.m.
New subject: [linux-audio-dev] Re: LADSPA Issues
Chris Cannam wrote:
There have been solutions to this problem for years:
http://en.wikipedia.org/wiki/Universally_Unique_Identifier
...if I'm not misunderstanding the issue.
Toby
So why
wasn't the unique ID the thing to use?
Because it's impossible to find any way to guarantee it's actually
unique, for example in the case of a wrapper plugin that generates
plugins on the fly.
20 May
20 May
7:39 a.m.
On Wed, May 18, 2005 at 10:16:43 +0100, Chris Cannam wrote:
On Wednesday 18 May 2005 09:56, Dave Robillard wrote:
Its only impossible because its centrally administered, if it were URI
based (or UUID etc.) then it would be much easier for fixed plugins, and
possible for most dynamic ones.
This was one of the problems that LADSPA 2.0 was supposed to solve.
- Steve
So why wasn't the unique ID the thing to use?
Because it's impossible to find any way to guarantee it's actually
unique, for example in the case of a wrapper plugin that generates
plugins on the fly. ladspa-vst / dssi-vst are obvious real-world
examples. (DSSI deprecates the LADSPA "unique" ID for this reason --
there are a few paragraphs about it in the current DSSI RFC.)
7181
days inactive
7188
days old
linux-audio-dev@lists.linuxaudio.org
10 comments
8 participants
participants (8)
-
Chris Cannam -
Dave Griffiths -
Dave Robillard -
Jens M Andreasen -
Nick Dowell -
Simon Jenkins -
Steve Harris -
Toby