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

On 24 Jun 2009, at 17:24, Stefano D'Angelo wrote: 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. 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

On Wed, Jun 24, 2009 at 8:22 PM, David Robillard<dave(a)drobilla.net> wrote: 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

2009/6/24 David Robillard <dave(a)drobilla.net>et>: 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

On Thu, Jun 25, 2009 at 05:25:48AM +0200, Stefano D'Angelo wrote: 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

2009/6/25 Jan Weil <jan.weil(a)web.de> 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

On Thu, Jun 25, 2009 at 4:49 PM, Stefano D'Angelo<zanga.mail(a)gmail.com> wrote: 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

2009/6/25 Chris Cannam <cannam(a)all-day-breakfast.com> 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...? 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). 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

On Thu, Jun 25, 2009 at 5:11 PM, Ralf Mardorf<ralf.mardorf(a)alice-dsl.net> wrote: 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

2009/6/25 Jan Weil <jan.weil(a)web.de> 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

2009/6/25 David Robillard <dave(a)drobilla.net>et>: 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

On 25 Jun 2009, at 18:01, Stefano D'Angelo wrote: 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

On Fri, Jun 26, 2009 at 11:39 AM, Steve Harris<steve(a)plugin.org.uk> wrote: Ah, so it's your fault! Chris

On 26 Jun 2009, at 11:50, Chris Cannam wrote: 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

Hi, On Thu, 25 Jun 2009, Stefano D'Angelo wrote: [using LADSPA unique ids] 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.

On Mon, Jul 6, 2009 at 5:01 AM, David Robillard<dave(a)drobilla.net> wrote: 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

On Mon, 2009-07-06 at 11:05 +0100, Chris Cannam wrote: 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. Never rely on the soname/label either. 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

On Tue, 7 Jul 2009 10:10:24 +0100 Chris Cannam <cannam(a)all-day-breakfast.com> wrote: 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

On 7 Jul 2009, at 11:06, Chris Cannam wrote: 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

On Tue, Jul 07, 2009 at 11:06:37AM +0100, Chris Cannam wrote: 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 -- FA Io lo dico sempre: l'Italia è troppo stretta e lunga.

On 7 Jul 2009, at 12:48, Chris Cannam wrote: Sure, that would actually be a bug though. Heh. - Steve