[LAD] RFC: Default discovery paths for LADSPA, LRDF, LV2 and DSSI (and more?)

[Stefano D'Angelo]

Hello

LADSPA, LV2 and DSSI specifications do not reccomend default discovery
paths where hosts may look for plugins, which IMO is bad for the end
user because:

* end users shouldn't be asked to know about path environment
variables by reading documentation in header files or looking for it
on the web;
* when their environment path variables are not set, some hosts choose
to scan some hard-coded directories, but this changes among hosts and
gets a lot worse on non UNIX-like operating systems (read Windows) -
for example some might look inside some subdirectory of the current
user's home, others might only look in /usr/lib/<api>, etc.

Hereby I propose some default paths which could be used, in the hope
that API authors lurking around here might want to recommend them and
host authors might want to use them:

LADSPA
Unix-like OSes with FHS/Unix-like filesystem layout:
/usr/lib/ladspa, /usr/local/lib/ladspa, ~/.ladspa
Windows: %PROGRAMFILES%\LADSPA, %APPDATA%\LADSPA
Mac OS X: /Library/Audio/Plug-Ins/LADSPA, ~/Library/Audio/Plug-Ins/LADSPA

DSSI
Unix-like OSes with FHS/Unix-like filesystem layout: /usr/lib/dssi,
/usr/local/lib/dssi, ~/.dssi
Windows: %PROGRAMFILES%\DSSI, %APPDATA%\DSSI
Mac OS X: /Library/Audio/Plug-Ins/DSSI, ~/Library/Audio/Plug-Ins/DSSI

LV2
Unix-like OSes with FHS/Unix-like filesystem layout: /usr/lib/lv2,
/usr/local/lib/lv2, ~/.lv2
Windows: %PROGRAMFILES%\LV2, %APPDATA%\LV2
Mac OS X: /Library/Audio/Plug-Ins/LV2, ~/Library/Audio/Plug-Ins/LV2

Plus, we could do the same for LRDF data:
Unix-like OSes with FHS/Unix-like filesystem layout:
/usr/share/ladspa/rdf, /usr/local/share/ladspa/rdf, ~/.ladspa/rdf
Windows: %PROGRAMFILES%\LADSPA\rdf, %APPDATA%\LADSPA\rdf
Mac OS X: /Library/Audio/Plug-Ins/LADSPA/rdf,
~/Library/Audio/Plug-Ins/LADSPA/rdf

What do you think about it?

Stefano

[Steve Harris]

http://lv2plug.in/docs/index.php?title=Filesystem_Locations
http://www.ladspa.org/ladspa_sdk/shared_plugins.html

- Steve

[Stefano D'Angelo]

Post by Steve Harris
http://lv2plug.in/docs/index.php?title=Filesystem_Locations
http://www.ladspa.org/ladspa_sdk/shared_plugins.html

Ah, good, I didn't know about those pages :-) (maybe link the lv2 one
in the specification page on lv2plug.in?)

Well, if we can do the same with Windows, LRDF and DSSI (Chris?), that
would be awesome (for example, IIRC Audacity looks for LADSPA plugins
in one of its subdirectories on Windows, which is bad IMO).

Stefano

[Steve Harris]

Post by Stefano D'Angelo

Post by Steve Harris
http://lv2plug.in/docs/index.php?title=Filesystem_Locations
http://www.ladspa.org/ladspa_sdk/shared_plugins.html

Ah, good, I didn't know about those pages :-) (maybe link the lv2 one
in the specification page on lv2plug.in?)

It's linked from the main page of the documentation: http://lv2plug.in/docs/index.php?title=Main_Page
That seems like the most appropriate place to me.

Post by Stefano D'Angelo
Well, if we can do the same with Windows, LRDF and DSSI (Chris?), that
would be awesome (for example, IIRC Audacity looks for LADSPA plugins
in one of its subdirectories on Windows, which is bad IMO).

LRDF defines where the RDF files should be, /usr/share/ladspa
something I think. It's obsoleted by LV2 anyway though. Converting
LADSPA+LRDF plugins to LV2 is easy.

I thought DSSI did define common paths, but perhaps not.

- Steve

[Stefano D'Angelo]

Post by Steve Harris

Post by Stefano D'Angelo

Post by Steve Harris
http://lv2plug.in/docs/index.php?title=Filesystem_Locations
http://www.ladspa.org/ladspa_sdk/shared_plugins.html

Ah, good, I didn't know about those pages :-) (maybe link the lv2 one
in the specification page on lv2plug.in?)

http://lv2plug.in/docs/index.php?title=Main_Page
That seems like the most appropriate place to me.

Ok, my bad.

Post by Steve Harris

Post by Stefano D'Angelo
Well, if we can do the same with Windows, LRDF and DSSI (Chris?), that
would be awesome (for example, IIRC Audacity looks for LADSPA plugins
in one of its subdirectories on Windows, which is bad IMO).

LRDF defines where the RDF files should be, /usr/share/ladspa something I
think. It's obsoleted by LV2 anyway though. Converting LADSPA+LRDF plugins
to LV2 is easy.

I can't find a place where such definition is made.

Then, AFAIK, TAP plugins and Rubberband have no LV2 port yet, and
maybe not everybody wants to port their plugins to LV2?

Stefano

[David Robillard]

Post by Stefano D'Angelo
Hereby I propose some default paths which could be used, in the hope
that API authors lurking around here might want to recommend them and
LADSPA
/usr/lib/ladspa, /usr/local/lib/ladspa, ~/.ladspa
Windows: %PROGRAMFILES%\LADSPA, %APPDATA%\LADSPA
Mac OS X: /Library/Audio/Plug-Ins/LADSPA, ~/Library/Audio/Plug-Ins/LADSPA
DSSI
Unix-like OSes with FHS/Unix-like filesystem layout: /usr/lib/dssi,
/usr/local/lib/dssi, ~/.dssi
Windows: %PROGRAMFILES%\DSSI, %APPDATA%\DSSI
Mac OS X: /Library/Audio/Plug-Ins/DSSI, ~/Library/Audio/Plug-Ins/DSSI
LV2
Unix-like OSes with FHS/Unix-like filesystem layout: /usr/lib/lv2,
/usr/local/lib/lv2, ~/.lv2
Windows: %PROGRAMFILES%\LV2, %APPDATA%\LV2
Mac OS X: /Library/Audio/Plug-Ins/LV2, ~/Library/Audio/Plug-Ins/LV2

Note the order matters for PATH-like variables such as these.

The LV2 discovery paths are documented here, FWIW:

http://lv2plug.in/docs/index.php?title=Filesystem_Locations

Cheers,

-dr

[Chris Cannam]

Post by David Robillard

Post by Stefano D'Angelo
Hereby I propose some default paths which could be used, in the hope
that API authors lurking around here might want to recommend them and
[...]

Note the order matters for PATH-like variables such as these.
http://lv2plug.in/docs/index.php?title=Filesystem_Locations

The DSSI documentation doesn't specify the path at all (sorry, Steve).

For what it's worth:

Rosegarden looks in ~/.dssi, /usr/local/lib/dssi and /usr/lib/dssi in
that order. Its default path for LADSPA is identical except with
ladspa instead of dssi.

The simple host in the DSSI distribution looks in /usr/local/lib/dssi,
/usr/lib/dssi and ~/.dssi, in that order. Yes, this is different from
Rosegarden! I could probably argue for either ordering, but I can't
easily justify the discrepancy. I suspect Rosegarden reflects my true
preference here.

(I've never really got on with the idea of using ~/.ladspa instead of
~/ladspa -- these are perhaps substantial binary files, why hide them
in a configuration directory? -- but it seemed to be widespread for
LADSPA hosts at the time DSSI was thought up, so we copied it for the
first DSSI hosts.)

For Vamp analysis plugins (http://vamp-plugins.org) I did include a
path recommendation, which is implemented by the plugin loader
included in the SDK. On Linux it is ~/vamp first, then
/usr/local/lib/vamp and /usr/lib/vamp, in that order. The provided
plugin loader actually looks in ~/.vamp as well -- a hangover from
LADSPA/DSSI and something I really ought to treat as a bug since all
the documentation differs. On OS/X the paths are
~/Library/Audio/Plug-Ins/Vamp and /Library/Audio/Plug-Ins/Vamp in that
order. On Windows the only location searched is "%ProgramFiles%\\Vamp
Plugins". Note that Vamp isn't a proper acronym, which is why the
paths say Vamp rather than VAMP.

Sonic Visualiser, my only cross-platform LADSPA host so far, uses the
same paths as Rosegarden on Linux. On OS/X its LADSPA and DSSI paths
are the same as those for Vamp above, but with LADSPA/DSSI (all caps)
instead of Vamp. On Windows, for LADSPA it looks in
"%ProgramFiles%\\LADSPA Plugins" followed by
"%ProgramFiles%\\Audacity\\Plug-Ins" (because many users will have
effects originally installed for Audacity which IIRC loads them only
from there) and for DSSI it looks in "%ProgramFiles%\\DSSI Plugins"
only.

In every case above, the default path is completely overridden by any
value found in the relevant one of the LADSPA_PATH, DSSI_PATH or
VAMP_PATH environment variables (colon-separated everywhere except on
Windows where it is semicolon-separated).


Chris

[Stefano D'Angelo]

Post by Chris Cannam

Post by David Robillard

Post by Stefano D'Angelo
Hereby I propose some default paths which could be used, in the hope
that API authors lurking around here might want to recommend them and
[...]

Note the order matters for PATH-like variables such as these.
http://lv2plug.in/docs/index.php?title=Filesystem_Locations

The DSSI documentation doesn't specify the path at all (sorry, Steve).
Rosegarden looks in ~/.dssi, /usr/local/lib/dssi and /usr/lib/dssi in
that order.  Its default path for LADSPA is identical except with
ladspa instead of dssi.
The simple host in the DSSI distribution looks in /usr/local/lib/dssi,
/usr/lib/dssi and ~/.dssi, in that order.  Yes, this is different from
Rosegarden!  I could probably argue for either ordering, but I can't
easily justify the discrepancy.  I suspect Rosegarden reflects my true
preference here.

I am asking this to you as well, Chris, how does this kind of ordering
affect discovery?

Post by Chris Cannam
(I've never really got on with the idea of using ~/.ladspa instead of
~/ladspa -- these are perhaps substantial binary files, why hide them
in a configuration directory? -- but it seemed to be widespread for
LADSPA hosts at the time DSSI was thought up, so we copied it for the
first DSSI hosts.)

IIRC Firefox lets you store plugins somewhere in ~/.mozilla, and WINE
places lots of stuff in ~/.wine... not that I say this is good or bad,
but it can maybe considered common practice??

[...]

Post by Chris Cannam
Sonic Visualiser, my only cross-platform LADSPA host so far, uses the
same paths as Rosegarden on Linux.  On OS/X its LADSPA and DSSI paths
are the same as those for Vamp above, but with LADSPA/DSSI (all caps)
instead of Vamp.  On Windows, for LADSPA it looks in
"%ProgramFiles%\\LADSPA Plugins" followed by
"%ProgramFiles%\\Audacity\\Plug-Ins" (because many users will have
effects originally installed for Audacity which IIRC loads them only
from there) and for DSSI it looks in "%ProgramFiles%\\DSSI Plugins"
only.

Defining default paths for plugins on Windows would allow
building/usage of installers and would let Audacity developers use
standard system- and user-wide directories :-)

We're also missing default paths for LADSPA and LRDF on Mac.

Post by Chris Cannam
In every case above, the default path is completely overridden by any
value found in the relevant one of the LADSPA_PATH, DSSI_PATH or
VAMP_PATH environment variables (colon-separated everywhere except on
Windows where it is semicolon-separated).

This is fine and all mentioned APIs could use this scheme (probably
most hosts work like that already).

Look, I really don't care about specific default values, I just think
that having some is a good thing. Probably a little drop into the
ocean for the adoption of free APIs, yet a must have IMO.

Stefano

[Chris Cannam]

Post by Stefano D'Angelo
I am asking this to you as well, Chris, how does this kind of ordering
affect discovery?

A library of a given name may exist in more than one place. Is it
preferable to allow the non-root user to override the system version
of the library with a newer, fixed version, or is it preferable to
ensure that system updates take priority over any possibly antique
version that the user installed locally when first testing the plugin
three years ago before it was packaged?

Post by Stefano D'Angelo
We're also missing default paths for LADSPA and LRDF on Mac.

SV uses ~/Library/Audio/Plug-Ins/LADSPA and
/Library/Audio/Plug-Ins/LADSPA for the plugins, and looks in a
subdirectory of each called "rdf" for LRDF files. Same goes for
Windows (i.e. "%ProgramFiles%\LADSPA Plugins\rdf"). Not that I
generally build with LRDF support on Windows anyway.


Chris

[Stefano D'Angelo]

Post by Stefano D'Angelo
I am asking this to you as well, Chris, how does this kind of ordering
affect discovery?

A library of a given name may exist in more than one place.  Is it
preferable to allow the non-root user to override the system version
of the library with a newer, fixed version, or is it preferable to
ensure that system updates take priority over any possibly antique
version that the user installed locally when first testing the plugin
three years ago before it was packaged?

What about using stat() to choose the latest?

Post by Stefano D'Angelo
We're also missing default paths for LADSPA and LRDF on Mac.

SV uses ~/Library/Audio/Plug-Ins/LADSPA and
/Library/Audio/Plug-Ins/LADSPA for the plugins, and looks in a
subdirectory of each called "rdf" for LRDF files.  Same goes for
Windows (i.e. "%ProgramFiles%\LADSPA Plugins\rdf").  Not that I
generally build with LRDF support on Windows anyway.

This makes sense to me, if only it could be made "official"...
(windows paths too)

Stefano

[Chris Cannam]

Post by Stefano D'Angelo
What about using stat() to choose the latest?

Well, I suppose the user might want the older-installed version to
take priority. I don't think it's all that unusual to deliberately
try to select the version of the plugin that you set up your presets
for in "the version of my session that sounded right", particularly if
you made it some time ago.

That said, if that's what you want to achieve, you could always just
"touch" the version you want. So long as you're aware of how the
lookup works.

I suppose my answer, then, would be (1) because it's more complicated
and (2) it doesn't seem to be how existing hosts do it, but (3) it
does sound like it an idea that might have merit.


Chris

[Stefano D'Angelo]

Post by Chris Cannam

Post by Stefano D'Angelo
What about using stat() to choose the latest?

Well, I suppose the user might want the older-installed version to
take priority. I don't think it's all that unusual to deliberately
try to select the version of the plugin that you set up your presets
for in "the version of my session that sounded right", particularly if
you made it some time ago.

This shouldn't be much of a problem in this particular case, since in LADSPA
says hosts should use filename and label to idenitfy a plugin. But I imagine
there are other cases in which this is not so simple...?

Post by Chris Cannam
That said, if that's what you want to achieve, you could always just
"touch" the version you want. So long as you're aware of how the
lookup works.

This is weird for the end user IMO. It is better to ask them which one to
use, or even load both? (The latter should work with LADSPA plugins, but I'm
afraid it's not that simple in LV2 - I don't know about VAMP and DSSI).

Post by Chris Cannam
I suppose my answer, then, would be (1) because it's more complicated
and (2) it doesn't seem to be how existing hosts do it, but (3) it
does sound like it an idea that might have merit.

Well, we just need a good way to do this, as usual I don't care which one it
is as long as it doesn't create problems.

Stefano

[Ralf Mardorf]

Post by Chris Cannam
Well, I suppose the user might want the older-installed version to
take priority.

Sorry, if I should miss the thread, but I randomly read the latest mail.

I'm using Linux and Windows and I like the behaviour for VST versions
(on Windows). Even if an old and new version have the same name, I can
rename the .dll for an VST on Windows and I have an old version plus the
newer version with a new name.

For a user this is a good solution to use older versions for older
projects and the latest version for actual projects.

I would like to have this behaviour for Linux too, because I now changed
for my DAW to Linux.

The green user should be able to have the possibility by simply changing
the name of the file, to have as much versions of a plug in, as he needs
to have.

I might have miss the thread, but the latest mail of this thread seems
to be about this issue. Sorry if I wrote pure nonsense.

[Chris Cannam]

Post by Ralf Mardorf

Post by Chris Cannam
Well, I suppose the user might want the older-installed version to
take priority.

Sorry, if I should miss the thread, but I randomly read the latest mail.
I'm using Linux and Windows and I like the behaviour for VST versions (on
Windows). Even if an old and new version have the same name, I can rename
the .dll for an VST on Windows and I have an old version plus the newer
version with a new name.

The difficulty with this for the common Linux plugin formats is that
the plugin itself specifies how it should be labelled on menus, etc.

So if you rename the plugin library, you may well get two different
versions of the plugin both loadable at once (I think this works in my
hosts, anyway) but the host will have to do something "clever" before
you can distinguish between them in your plugin selector. (For
example, Sonic Visualiser will append the library name after the
plugin name in the menu if the same plugin name is found in multiple
libraries.)

In principle this situation can happen even if the plugins are not the
same (two developers use the same description), so hosts really ought
to address it anyway, but I imagine it's not widely tested for.

For LADSPA hosts that identify plugins by "unique" ID, however, you're
probably screwed. I think that's a terrible way to identify a plugin
even for a LADSPA-only host, but it's not uncommon.


Chris

[Steve Harris]

On Thu, Jun 25, 2009 at 4:49 PM, Stefano

Post by Stefano D'Angelo
What about using stat() to choose the latest?

Well, I suppose the user might want the older-installed version to
take priority. I don't think it's all that unusual to deliberately
try to select the version of the plugin that you set up your presets
for in "the version of my session that sounded right", particularly if
you made it some time ago.
That said, if that's what you want to achieve, you could always just
"touch" the version you want. So long as you're aware of how the
lookup works.
I suppose my answer, then, would be (1) because it's more complicated
and (2) it doesn't seem to be how existing hosts do it, but (3) it
does sound like it an idea that might have merit.

I think the surprise element for users is too great, if you do a naive
backup-restore with cp or so then it will play havoc. It's just not
the sort of thing I'd expect to have any effect on app behaviour.

- Steve

[David Robillard]

Post by Chris Cannam
(I've never really got on with the idea of using ~/.ladspa instead of
~/ladspa -- these are perhaps substantial binary files, why hide them
in a configuration directory? -- but it seemed to be widespread for
LADSPA hosts at the time DSSI was thought up, so we copied it for the
first DSSI hosts.)

It would be nice to stick with this, but it doesn't seem to really have
a place for plugins:

http://standards.freedesktop.org/basedir-spec/basedir-spec-0.6.html


-dr

[Stefano D'Angelo]

Post by David Robillard

Post by Chris Cannam
(I've never really got on with the idea of using ~/.ladspa instead of
~/ladspa -- these are perhaps substantial binary files, why hide them
in a configuration directory? -- but it seemed to be widespread for
LADSPA hosts at the time DSSI was thought up, so we copied it for the
first DSSI hosts.)

It would be nice to stick with this, but it doesn't seem to really have
http://standards.freedesktop.org/basedir-spec/basedir-spec-0.6.html

Uhm, maybe we should talk to the author?

Anyway, regarding multiple occourrences of plugins, the following
stuff emerged so far:

* LADSPA header asks hosts to identify plugins by filename and label,
which implies:
- two plugins with same UniqueID and/or label are different plugins (lame);
- files containing sessions/patches/etc. are not portable beetween
different systems or different versions of the same system (lame).
* LV2 identifies plugins by URI, which means:
- in case of multiple plugins with the same URI someone has to decide
which one to use - the host, maybe by choosing according to the
discovery order (bad for the unaware end user, and maybe even
inconsitent in case the two bundles are in the same directory) or the
user (better, but maybe a bit harder to handle in support libraries
like SLV2?).
* DSSI header file does not specify how a DSSI plugin should be
identified by the host, but a DSSI plugin descriptors contains
reference to a LADSPA plugin descriptors, which maybe implies the same
kind of identification maybe?
* what about VAMP? (VampPluginDescriptor.identifier maybe??)

It would be cool to use the same "strategy" with all APIs (and this is
the right time to do it, new versions of LV2 and LADSPA in the
making), but at least we need well defined rules for each API.

Then, we are missing:
* LADSPA: default paths on Windows and Mac OS X;
* LV2: defaults paths on Windows (I read a *TODO* there);
* DSSI: default paths for DSSI_PATH;
* VAMP: default paths (we could use Vamp SDK's ones?).
* LRDF: default paths in any case.

Then, we also have other free APIs such as libzzub/Armstrong,
gstreamer, etc. - maybe we could steal from there?

Stefano

[Chris Cannam]

Post by Stefano D'Angelo
* LADSPA header asks hosts to identify plugins by filename and label,
 - two plugins with same UniqueID and/or label are different plugins (lame);
 - files containing sessions/patches/etc. are not portable beetween
different systems or different versions of the same system (lame).

I always interpreted "filename" as meaning base name (i.e. the bit
between the last "/" and the .so) myself, which avoids both of these
problems.

Post by Stefano D'Angelo
 - in case of multiple plugins with the same URI someone has to decide
which one to use - the host, maybe by choosing according to the
discovery order (bad for the unaware end user, and maybe even
inconsitent in case the two bundles are in the same directory) or the
user (better, but maybe a bit harder to handle in support libraries
like SLV2?).

I imagine LV2 requires that plugins with identical URIs should behave
identically.

Post by Stefano D'Angelo
* DSSI header file does not specify how a DSSI plugin should be
identified by the host

IIRC the RFC mentions filename+label (and includes a stern warning not
to use LADSPA "unique" IDs).

Post by Stefano D'Angelo
* what about VAMP? (VampPluginDescriptor.identifier maybe??)

Library base name plus identifier (i.e. basically the same as my
interpretation of the LADSPA/DSSI case).

Post by Stefano D'Angelo
* VAMP: default paths (we could use Vamp SDK's ones?).

A host would need a pretty good reason to do anything else; the paths
are documented, and all existing hosts use the SDK to load their
plugins from it anyway.


Chris

[Stefan Kost]

Post by David Robillard

Post by Chris Cannam
(I've never really got on with the idea of using ~/.ladspa instead of
~/ladspa -- these are perhaps substantial binary files, why hide them
in a configuration directory? -- but it seemed to be widespread for
LADSPA hosts at the time DSSI was thought up, so we copied it for the
first DSSI hosts.)

It would be nice to stick with this, but it doesn't seem to really have
http://standards.freedesktop.org/basedir-spec/basedir-spec-0.6.html

Yes, please no more ~/.xyz dirs. One problem is that the spec only talks about
DATA_DIR -> e.g. rdf files, docs, ... equiv of e.g. /usr/share
CONFIG_DIR -> settings, equiv of /etc
CACHE_DIR -> e.g. a plugin cache, equiv of /var/cache

but there is nothing for plugins (equiv of /usr/lib)

I'll write to xdg-list ...

Stefan

Post by David Robillard
-dr
_______________________________________________
Linux-audio-dev mailing list
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

[Steve Harris]

Post by Chris Cannam
(I've never really got on with the idea of using ~/.ladspa instead of
~/ladspa -- these are perhaps substantial binary files, why hide them
in a configuration directory? -- but it seemed to be widespread for
LADSPA hosts at the time DSSI was thought up, so we copied it for the
first DSSI hosts.)

FWIW, I don't like it when apps create or use files in my home
directory that don't start with a dot, it makes my $HOME messy and
conflicts with my preferred arrangement of directories in some cases.

- Steve

[Chris Cannam]

Post by Chris Cannam
(I've never really got on with the idea of using ~/.ladspa instead of
~/ladspa -- these are perhaps substantial binary files, why hide them
in a configuration directory? -- but it seemed to be widespread for
LADSPA hosts at the time DSSI was thought up, so we copied it for the
first DSSI hosts.)

FWIW, I don't like it when apps create or use files in my home directory
that don't start with a dot, it makes my $HOME messy and conflicts with my
preferred arrangement of directories in some cases.

Ah, so it's your fault!


Chris

[Steve Harris]

Post by Chris Cannam

Post by Chris Cannam
(I've never really got on with the idea of using ~/.ladspa instead of
~/ladspa -- these are perhaps substantial binary files, why hide them
in a configuration directory? -- but it seemed to be widespread for
LADSPA hosts at the time DSSI was thought up, so we copied it for the
first DSSI hosts.)

FWIW, I don't like it when apps create or use files in my home directory
that don't start with a dot, it makes my $HOME messy and conflicts with my
preferred arrangement of directories in some cases.

Ah, so it's your fault!

Heh, I don't think I'm solely to blame :)

I don't object to the way OSX does it, with ~/Library/... that's just
one directory with some app-specific rubbish in sub directories, but
it's a bit late to go down that route in Linux.

- Steve

[Stefano D'Angelo]

Post by David Robillard

Post by Stefano D'Angelo
Hereby I propose some default paths which could be used, in the hope
that API authors lurking around here might want to recommend them and
LADSPA
/usr/lib/ladspa, /usr/local/lib/ladspa, ~/.ladspa
  Windows: %PROGRAMFILES%\LADSPA, %APPDATA%\LADSPA
  Mac OS X: /Library/Audio/Plug-Ins/LADSPA, ~/Library/Audio/Plug-Ins/LADSPA
DSSI
  Unix-like OSes with FHS/Unix-like filesystem layout: /usr/lib/dssi,
/usr/local/lib/dssi, ~/.dssi
  Windows: %PROGRAMFILES%\DSSI, %APPDATA%\DSSI
  Mac OS X: /Library/Audio/Plug-Ins/DSSI, ~/Library/Audio/Plug-Ins/DSSI
LV2
  Unix-like OSes with FHS/Unix-like filesystem layout: /usr/lib/lv2,
/usr/local/lib/lv2, ~/.lv2
  Windows: %PROGRAMFILES%\LV2, %APPDATA%\LV2
  Mac OS X: /Library/Audio/Plug-Ins/LV2, ~/Library/Audio/Plug-Ins/LV2

Note the order matters for PATH-like variables such as these.

Apart from the "evaluate the path variable before using the default" I
don't see how the order should matter. Am I missing something?

Stefano

[Jan Weil]

Post by Stefano D'Angelo

Post by David Robillard

Post by Stefano D'Angelo
Hereby I propose some default paths which could be used, in the hope
that API authors lurking around here might want to recommend them and
LADSPA
/usr/lib/ladspa, /usr/local/lib/ladspa, ~/.ladspa
  Windows: %PROGRAMFILES%\LADSPA, %APPDATA%\LADSPA
  Mac OS X: /Library/Audio/Plug-Ins/LADSPA, ~/Library/Audio/Plug-Ins/LADSPA
DSSI
  Unix-like OSes with FHS/Unix-like filesystem layout: /usr/lib/dssi,
/usr/local/lib/dssi, ~/.dssi
  Windows: %PROGRAMFILES%\DSSI, %APPDATA%\DSSI
  Mac OS X: /Library/Audio/Plug-Ins/DSSI, ~/Library/Audio/Plug-Ins/DSSI
LV2
  Unix-like OSes with FHS/Unix-like filesystem layout: /usr/lib/lv2,
/usr/local/lib/lv2, ~/.lv2
  Windows: %PROGRAMFILES%\LV2, %APPDATA%\LV2
  Mac OS X: /Library/Audio/Plug-Ins/LV2, ~/Library/Audio/Plug-Ins/LV2

Note the order matters for PATH-like variables such as these.

Apart from the "evaluate the path variable before using the default" I
don't see how the order should matter. Am I missing something?

I guess it might matter if you have multiple version of the same plugin
installed, depending on how the application references the plugins.
Ecasound, for example, uses LADSPA unique ids if I remember correctly,
which means only one of the multiple versions will be usable. Which one
that is probably depends on the order of the paths.

Jan

[Stefano D'Angelo]

Post by Stefano D'Angelo

Post by Stefano D'Angelo

Post by David Robillard

Post by Stefano D'Angelo
Hereby I propose some default paths which could be used, in the hope
that API authors lurking around here might want to recommend them and
LADSPA
/usr/lib/ladspa, /usr/local/lib/ladspa, ~/.ladspa
Windows: %PROGRAMFILES%\LADSPA, %APPDATA%\LADSPA
Mac OS X: /Library/Audio/Plug-Ins/LADSPA,

~/Library/Audio/Plug-Ins/LADSPA

Post by Stefano D'Angelo

Post by David Robillard

Post by Stefano D'Angelo
DSSI
Unix-like OSes with FHS/Unix-like filesystem layout: /usr/lib/dssi,
/usr/local/lib/dssi, ~/.dssi
Windows: %PROGRAMFILES%\DSSI, %APPDATA%\DSSI
Mac OS X: /Library/Audio/Plug-Ins/DSSI,

~/Library/Audio/Plug-Ins/DSSI

Post by Stefano D'Angelo

Post by David Robillard

Post by Stefano D'Angelo
LV2
Unix-like OSes with FHS/Unix-like filesystem layout: /usr/lib/lv2,
/usr/local/lib/lv2, ~/.lv2
Windows: %PROGRAMFILES%\LV2, %APPDATA%\LV2
Mac OS X: /Library/Audio/Plug-Ins/LV2, ~/Library/Audio/Plug-Ins/LV2

Note the order matters for PATH-like variables such as these.

Apart from the "evaluate the path variable before using the default" I
don't see how the order should matter. Am I missing something?

I guess it might matter if you have multiple version of the same plugin
installed, depending on how the application references the plugins.
Ecasound, for example, uses LADSPA unique ids if I remember correctly,
which means only one of the multiple versions will be usable. Which one
that is probably depends on the order of the paths.

That is bad of Ecasound, since ladspa.h says:

"Plugin types should be identified by file and label rather than by index or
plugin name, which may be changed in new plugin versions."

In case of multiple occourrences, myabe it's better to check for stat()'s
st_mtime to decide which one to load? However, I don't see any of such
mechanisms officially specified anywhere (apart from the "If present, this
should contain a colon-separated path indicating directories that should be
searched (in order) when loading plugin types." in ladspa.h, which really
means nothing)...

Stefano

[Jan Weil]

Post by Stefano D'Angelo
In case of multiple occourrences, myabe it's better to check for stat()'s
st_mtime to decide which one to load? However, I don't see any of such
mechanisms officially specified anywhere (apart from the "If present, this
should contain a colon-separated path indicating directories that should be
searched (in order) when loading plugin types." in ladspa.h, which really
means nothing)...

In my opinion, the host should not try to decide anything in this case.
Don't try to be clever. Just present all of the available versions to
the user and let him/her choose. Most of the time you don't want
multiple versions of your plugins on your system and, what is more, you
might even not be aware that there is a conflict. Of course, this is not
the way PATH-like variables are usually used, but even in the case of
PATH we know similar problems (multiple versions of jackd etc.).

Jan

[Stefano D'Angelo]

Post by Chris Cannam

Post by Stefano D'Angelo
In case of multiple occourrences, myabe it's better to check for stat()'s
st_mtime to decide which one to load? However, I don't see any of such
mechanisms officially specified anywhere (apart from the "If present,

this

Post by Stefano D'Angelo
should contain a colon-separated path indicating directories that should

be

Post by Stefano D'Angelo
searched (in order) when loading plugin types." in ladspa.h, which

really

Post by Stefano D'Angelo
means nothing)...

In my opinion, the host should not try to decide anything in this case.
Don't try to be clever. Just present all of the available versions to
the user and let him/her choose. Most of the time you don't want
multiple versions of your plugins on your system and, what is more, you
might even not be aware that there is a conflict. Of course, this is not
the way PATH-like variables are usually used, but even in the case of
PATH we know similar problems (multiple versions of jackd etc.).

It is reasonable for LADSPA hosts to show duplicate versions of a plugin,
for LV2 I guess the user would have to choose which implementation to use
instead (this is because of URIs), unless there are better ways to handle
this... Dave?

Stefano

[Steve Harris]

Post by Stefano D'Angelo
It is reasonable for LADSPA hosts to show duplicate versions of a
plugin, for LV2 I guess the user would have to choose which
implementation to use instead (this is because of URIs), unless
there are better ways to handle this... Dave?

It's not reasonable unless they have different LADPSA IDs. LADSPA
plugins are not supposed to change their behaviour significantly
without changing IDs.

It's not really a tenable situation anyway, how would the user pick
between them? If you want to move apps, how would the other host pick
the same one reliably?

- Steve

[Ralf Mardorf]

Post by Jan Weil
(multiple versions of jackd etc.).

For Linux I'm just a user and not a coder, so my input here might not be
clever, but it's from the sight of a user ;).

If I'm fine with versions of libs, I might use a new Linux install too,
because for some reasons there might be the need to use also some new
dependencies, but I still can keep an old Linux installation too, space
on hard discs isn't expensive these day (and I'm really poor for a
European).

Assumed that I want to work on an old project with some old DSSIs and
LADSPAs (until now there seems to be less LV2s) and dependencies still
would be fine for different versions off plug ins, it would be good if I
can chose the version.

If I understand it right, it might be that two coders randomly can use
identical descriptions and the user can run into trouble because of
this. I guess a coder simply can describe his plug in unique.

Instead of 'compressor', 'compressor_by_coder_x_version_y'. I don't know
if it's that easy ;), because I don't have knowledge about the
standards. The names that appear in my hosts are similar to 'my idea',
e.g. 'C* Blabla' and TAB Blabla', in addition there only seems to be the
need to add the version.

Isn't it that easy?

Ralf

[Kai Vehmanen]

Hi,

On Thu, 25 Jun 2009, Stefano D'Angelo wrote:
[using LADSPA unique ids]

"Plugin types should be identified by file and label rather than by index or plugin name, which may be changed in
new plugin versions."

Ecasound allows to use both label (-el) and unique id (-eli) to identify
plugins. In many cases label is sufficient (versus file+label), and in the
rare case of a conflict, then unique-id is a practical way to select the
correct plugin. At least nobody has complained about the current
implementation so far. Still, adding a 3rd option (file+label) is perhaps
not a bad idea. It's just that for command-line line use, the shorter
variants are less cumbersome to use.

[David Robillard]

Post by Kai Vehmanen
Hi,
[using LADSPA unique ids]

"Plugin types should be identified by file and label rather than by index or plugin name, which may be changed in
new plugin versions."

This is an error in ladspa.h

Post by Kai Vehmanen
Ecasound allows to use both label (-el) and unique id (-eli) to identify
plugins. In many cases label is sufficient (versus file+label), and in the
rare case of a conflict, then unique-id is a practical way to select the
correct plugin.

There are conflicts with the unique ID too, but there's no accounting
for broken plugins I guess.

I don't know why people started recommending using the filename/label
over the unique ID, but they shouldn't. This varies even between
different packages of the exact same plugins (e.g. blop, notoriously),
and it's clear from the spec that file/label isn't intended to be
important as an identifier... there's an ID in there, use it.

-dr

[Chris Cannam]

Post by David Robillard
There are conflicts with the unique ID too, but there's no accounting
for broken plugins I guess.

Filename/label can be made to work; "unique" ID can't, for any dynamic
or automatically generated plugin library.

Take dssi-vst for example. It consists of a single library that
publishes many LADSPA plugins, whose number and type are unknown until
run time. It can't map them onto a reserved range because it doesn't
know in advance what plugins it may have to wrap. It can't
realistically generate a good hashed value, because of the range
limitation given in the LADSPA header ("below 0x1000000") and the need
to avoid reserved ranges. It can't pass through the VST plugin's
existing numerical ID, because these are typically generated by
mapping from strings or hashing, and consequently are also usually out
of range, and anyway it can't know whether a LADSPA plugin of the same
ID already exists.

I was sorely tempted to make it use the unique ID of 1 for every
plugin. I didn't, but the method it actually uses is really no better
in practice.

I realise many on this list won't care about wrapping VSTs, but any
generated wrapper plugin (e.g. from Faust) will have the same problem.

Never rely on the "unique" ID of a LADSPA plugin.

(URIs are far better than either filename/label or numerical ID of course.)


Chris

[Stefano D'Angelo]

Post by Chris Cannam

Post by David Robillard
There are conflicts with the unique ID too, but there's no accounting
for broken plugins I guess.

Filename/label can be made to work; "unique" ID can't, for any dynamic
or automatically generated plugin library.
Take dssi-vst for example.  It consists of a single library that
publishes many LADSPA plugins, whose number and type are unknown until
run time.  It can't map them onto a reserved range because it doesn't
know in advance what plugins it may have to wrap.  It can't
realistically generate a good hashed value, because of the range
limitation given in the LADSPA header ("below 0x1000000") and the need
to avoid reserved ranges.  It can't pass through the VST plugin's
existing numerical ID, because these are typically generated by
mapping from strings or hashing, and consequently are also usually out
of range, and anyway it can't know whether a LADSPA plugin of the same
ID already exists.
I was sorely tempted to make it use the unique ID of 1 for every
plugin.  I didn't, but the method it actually uses is really no better
in practice.
I realise many on this list won't care about wrapping VSTs, but any
generated wrapper plugin (e.g. from Faust) will have the same problem.
Never rely on the "unique" ID of a LADSPA plugin.
(URIs are far better than either filename/label or numerical ID of course.)

/me quotes Chris entirely.

Stefano

[David Robillard]

Post by Chris Cannam

Post by David Robillard
There are conflicts with the unique ID too, but there's no accounting
for broken plugins I guess.

Filename/label can be made to work; "unique" ID can't, for any dynamic
or automatically generated plugin library.
Take dssi-vst for example. It consists of a single library that
publishes many LADSPA plugins, whose number and type are unknown until
run time. It can't map them onto a reserved range because it doesn't
know in advance what plugins it may have to wrap. It can't
realistically generate a good hashed value, because of the range
limitation given in the LADSPA header ("below 0x1000000") and the need
to avoid reserved ranges. It can't pass through the VST plugin's
existing numerical ID, because these are typically generated by
mapping from strings or hashing, and consequently are also usually out
of range, and anyway it can't know whether a LADSPA plugin of the same
ID already exists.

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.

Should LADSPA have used a better ID? Yes.
Did it? No.
Is soname:label an ID for a given plugin? No.

Post by Chris Cannam
Never rely on the "unique" ID of a LADSPA plugin.

Never rely on the soname/label either.

Post by Chris Cannam
(URIs are far better than either filename/label or numerical ID of course.)

Bingo.

If people are seriously considering a new ladspa revision, this is
something that should actually be taken care of. Far more important
than what got that ball rolling in the first place...

-dr

[Chris Cannam]

Post by David Robillard
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

[h***@gmx.at]

On Tue, 7 Jul 2009 10:10:24 +0100

Post by Chris Cannam

Post by David Robillard
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

[Chris Cannam]

Post by h***@gmx.at
Changing the ID with every plugin change seems ridiculous

Well, it's just a question for your own judgment. Regardless of the
sort of identifier you use, when you change it your plugin will appear
to be a different plugin, so you need to decide whether a change is
big enough that your new version can't directly stand in for the old.
That's all.

Post by h***@gmx.at
"- 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

no further comment m'lud.


Chris

[Steve Harris]

Post by Chris Cannam

Post by h***@gmx.at
Changing the ID with every plugin change seems ridiculous

Well, it's just a question for your own judgment. Regardless of the
sort of identifier you use, when you change it your plugin will appear
to be a different plugin, so you need to decide whether a change is
big enough that your new version can't directly stand in for the old.
That's all.

Post by h***@gmx.at
"- 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

no further comment m'lud.

I'm disinclined to think too much about how to fix LADSPA, all these
problems and more are fixed in LV2. Plugin developers should be
migrating off LADSPA.

But, what about, from now on, all LADSPA labels should be the plugin
URI (only restriction is non whitespace, fine), and the UID should be
(MD5($uri) % 2^32) & 0x1000000 so it doesn't clash with the previous
allocated space. There's a reasonable chance of collisions if we have
2^15 plugins in the wild (lets hope not), but as has been said,
globally unique integer IDs are just a bad idea anyway.

Will break any hosts the check to see if the UID is in the legitimate
range of course.

- Steve

[Chris Cannam]

Post by Steve Harris
But, what about, from now on, all LADSPA labels should be the plugin
URI (only restriction is non whitespace, fine)

Nice in theory, though one problem with my preference for using
filename/label is that it offers more scope for weird programmer
foibles. The only restriction in the spec may be "no whitespace", but
I expect hosts may have other peculiarities. I haven't checked but I
wouldn't be surprised if some of my own code breaks if certain
characters are found in the label ('"', ':', '<', '>', '&' spring to
mind as possible candidates). And let's just wait for the first
security advisory for a buffer overflow in LADSPA plugin label
handling...

Post by Steve Harris
Will break any hosts the check to see if the UID is in the legitimate
range of course.

... though that said, people do dumb things with numbers too
sometimes. I have seen code that tried to store LADSPA plugin IDs in
floats (!) thus ending up with rounding error for large ID values.
(Not my code, honest.)


Chris

[Steve Harris]

Post by Chris Cannam

Post by Steve Harris
But, what about, from now on, all LADSPA labels should be the plugin
URI (only restriction is non whitespace, fine)

Nice in theory, though one problem with my preference for using
filename/label is that it offers more scope for weird programmer
foibles. The only restriction in the spec may be "no whitespace", but
I expect hosts may have other peculiarities. I haven't checked but I
wouldn't be surprised if some of my own code breaks if certain
characters are found in the label ('"', ':', '<', '>', '&' spring to
mind as possible candidates). And let's just wait for the first
security advisory for a buffer overflow in LADSPA plugin label
handling...

Sure, that would actually be a bug though.

Post by Chris Cannam

Post by Steve Harris
Will break any hosts the check to see if the UID is in the legitimate
range of course.

... though that said, people do dumb things with numbers too
sometimes. I have seen code that tried to store LADSPA plugin IDs in
floats (!) thus ending up with rounding error for large ID values.
(Not my code, honest.)

Heh.

- Steve

[Fons Adriaensen]

Post by Chris Cannam
Well, it's just a question for your own judgment. Regardless of the
sort of identifier you use, when you change it your plugin will appear
to be a different plugin, so you need to decide whether a change is
big enough that your new version can't directly stand in for the old.

That is indeed the real question and it does not
always have clear answer.

AFAIK, there's no version number for a LADSPA,
plugin, apart from what gets encoded into the
name or label.

I had an unclear situation recently with the new
release of the 4-band parametric EQ. It has the same
parameters and parameter ranges as the previous one,
but the mapping from the combination gain/bandwidth
to a particular FR has changed - there are different
ways to do this, all of them logical and consistent,
they just give a different 'feel'.

So the new version will work perfectly in e.g. an
Ardour session using the old one, but you may want
to re-adjust its settings.

Compatible or not ?

Ciao

[Chris Cannam]

Post by Fons Adriaensen
Compatible or not ?

I don't think that there is a good answer for this, without the plugin
API providing a versioning system that the host actually understands
is a versioning system (so that it can do something sensible such as
loading the plugin but notifying the user that the version has changed
-- different behaviour from what you should expect if the plugin had
changed quite incompatibly).

Since LADSPA has no such thing, I don't think there is any
satisfactory answer for this plugin. One possibility that could in
theory work sometimes would be to provide a new parameter to control
whatever quality it was that changed (it could be as trivial as an
"old/new" toggle -- but what should its default be?).

This kind of subject is a minefield and probably always will be, since
solutions that are comprehensive enough to be effective in practice
are likely to be also just complicated enough to vary significantly in
implementation. It's particularly problematic of course on a platform
in which people routinely get updates to their software without
explicitly asking for them.


Chris

[Jeff McClintock]

Post by Stefano D'Angelo

Windows (i.e. "%ProgramFiles%\LADSPA Plugins\rdf"). ?Not that I
generally build with LRDF support on Windows anyway.

This makes sense to me, if only it could be made "official"...
(windows paths too)

Windows has official rules for this. Users are no longer allowed to add
random files to an application's directory in "/Program Files/Appname".
Permissions are set to prevent it and that directory is virtualized to
prevent it.
The exception is - Applications can install their own bundled plugins in
"/Program Files/Appname" at install time only (because the installer has
elevated privilege).

User installed plugins go in CSIDL_PROGRAM_FILES_COMMON , e.g. typically
"C:\Program Files\Common Files\LADSPA Plugins..."

Best Regards,
Jeff McClintock

[Chris Cannam]

Windows has official rules for this.  Users are no longer allowed to add
random files to an application's directory in "/Program Files/Appname".

Oh! This is news to me -- interesting news too, given that I
distribute Windows versions of SV without an installer and just expect
the user to copy it to %ProgramFiles% if they want it to go there, and
that it only looks in immediate subdirectories of %ProgramFiles% for
plugins of any sort.

I don't recall anyone complaining to me that they couldn't install
plugins for it -- maybe this just means nobody is using it?!

Can you point to any documentation for this? I'd like to know what
other rules I might be falling afoul of.

User installed plugins go in CSIDL_PROGRAM_FILES_COMMON , e.g. typically
"C:\Program Files\Common Files\LADSPA Plugins..."

I don't suppose you happen to know whether any Windows-based LADSPA
hosts are actually using this path?


Chris

[Ralf Mardorf]

Post by Chris Cannam

Post by Jeff McClintock
Windows has official rules for this. Users are no longer allowed to add
random files to an application's directory in "/Program Files/Appname".

Oh! This is news to me -- interesting news too, given that I
distribute Windows versions of SV without an installer and just expect
the user to copy it to %ProgramFiles% if they want it to go there, and
that it only looks in immediate subdirectories of %ProgramFiles% for
plugins of any sort.
I don't recall anyone complaining to me that they couldn't install
plugins for it -- maybe this just means nobody is using it?!
Can you point to any documentation for this? I'd like to know what
other rules I might be falling afoul of.

Post by Jeff McClintock
User installed plugins go in CSIDL_PROGRAM_FILES_COMMON , e.g. typically
"C:\Program Files\Common Files\LADSPA Plugins..."

I don't suppose you happen to know whether any Windows-based LADSPA
hosts are actually using this path?
Chris

I'm going to delete my Windows installation, but if I can help by
keeping it and you ask me explicit to test some behaviour I will do it.

[Ralf Mardorf]

Post by Ralf Mardorf

Post by Chris Cannam

Post by Jeff McClintock
Windows has official rules for this. Users are no longer allowed to add
random files to an application's directory in "/Program Files/Appname".

Oh! This is news to me -- interesting news too, given that I
distribute Windows versions of SV without an installer and just expect
the user to copy it to %ProgramFiles% if they want it to go there, and
that it only looks in immediate subdirectories of %ProgramFiles% for
plugins of any sort.
I don't recall anyone complaining to me that they couldn't install
plugins for it -- maybe this just means nobody is using it?!
Can you point to any documentation for this? I'd like to know what
other rules I might be falling afoul of.

Post by Jeff McClintock
User installed plugins go in CSIDL_PROGRAM_FILES_COMMON , e.g. typically
"C:\Program Files\Common Files\LADSPA Plugins..."

I don't suppose you happen to know whether any Windows-based LADSPA
hosts are actually using this path?
Chris

I'm going to delete my Windows installation, but if I can help by
keeping it and you ask me explicit to test some behaviour I will do it.

Pardon, I need some time to understand that it was ironic, I will be
quiet now ;) ... sorry.

[Ralf Mardorf]

Post by Jeff McClintock

Post by Stefano D'Angelo

Windows (i.e. "%ProgramFiles%\LADSPA Plugins\rdf"). ?Not that I
generally build with LRDF support on Windows anyway.

This makes sense to me, if only it could be made "official"...
(windows paths too)

Windows has official rules for this. Users are no longer allowed to add
random files to an application's directory in "/Program Files/Appname".
Permissions are set to prevent it and that directory is virtualized to
prevent it.
The exception is - Applications can install their own bundled plugins in
"/Program Files/Appname" at install time only (because the installer has
elevated privilege).
User installed plugins go in CSIDL_PROGRAM_FILES_COMMON , e.g. typically
"C:\Program Files\Common Files\LADSPA Plugins..."
Best Regards,
Jeff McClintock

I need to take a look at my Windows installation, that I will delete,
because Linux now is fine on my machine, but as far as I remember VSTs
are in \Blabla\Steinberg\VST or similar to this and a user can rename
and add what ever he likes to this path AND Cakewalk or what ever, will
take a look too, to this directory. It might be different for LADSPAs on
Windows, but there seems to be still an advantage the way VSTs are used.

[Jeff McClintock]

From: Chris Cannam

Windows has official rules for this. ?Users are no longer allowed to

add

random files to an application's directory in "/Program

Files/Appname".
Oh! This is news to me -- interesting news too, given that I
distribute Windows versions of SV without an installer and just expect
the user to copy it to %ProgramFiles% if they want it to go there, and
that it only looks in immediate subdirectories of %ProgramFiles% for
plugins of any sort.
I don't recall anyone complaining to me that they couldn't install
plugins for it -- maybe this just means nobody is using it?!

On Windows XP, many people run as administrator, so they won't notice
anything. On Vista and Windows 7, they will get a 'UAC' Warning that they
are doing something restricted.

Can you point to any documentation for this? I'd like to know what
other rules I might be falling afoul of.

http://msdn.microsoft.com/en-us/library/ms995843.aspx

(most of that is about system dlls and versioning). The relevant part for
plugins is...

" 3.4 Install any non side-by-side shared files to the correct locations
The proper location for shared components depends on whether these
components are shared across companies or by a single company.

Shared components that are private to a single software vendor must be
installed in one of two places. Do not store these files in the system
directory

common files directory\<company name>
%ProgramFiles%\<company name>\Shared Files

The common files directory can be accessed by passing
CSIDL_PROGRAM_FILES_COMMON to the SHGetFolderPath API."

typically

"C:\Program Files\Common Files\LADSPA Plugins..."

I don't suppose you happen to know whether any Windows-based LADSPA
hosts are actually using this path?

I don't know about LADSPA..but the latest Cubase uses "C:\Program
Files\Common Files\Steinberg\VST2" for 3rd party plugins.

Personally I think the company name could be omitted because many other
individuals and companies need to put plugins in there too.

Jeff M

[Ralf Mardorf]

Post by Jeff McClintock
On Windows XP, many people run as administrator

Definitive!

Post by Jeff McClintock
I don't know about LADSPA..but the latest Cubase uses "C:\Program
Files\Common Files\Steinberg\VST2" for 3rd party plugins.

On my machine it's '/media/disk/Programme/Steinberg/VstPlugins', resp.
'C:\Programme\Steinberg\VstPlugins' ;) and as I have written before, I
can make different versions available by just renaming the file, e.g.
there's a compressor version without 'sse' and another with 'sse', so I
just added '_sse' to the file name.

[Chris Cannam]

Post by Jeff McClintock

From: Chris Cannam
Can you point to any documentation for this?  I'd like to know what
other rules I might be falling afoul of.

http://msdn.microsoft.com/en-us/library/ms995843.aspx
(most of that is about system dlls and versioning). The relevant part for
plugins is...
" 3.4  Install any non side-by-side shared files to the correct locations
The proper location for shared components depends on whether these
components are shared across companies or by a single company.
[...]

I've only just got around to reading this properly, but it seems to be
saying the opposite of what you said -- it seems to be saying that
components that are shared across multiple vendors (such as audio
plugins of this type, presumably) may indeed be placed in the system
directory. Am I reading it wrong?


Chris