2009/6/24 Steve Harris <steve(a)plugin.org.uk>uk>: 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

2009/6/24 Steve Harris <steve(a)plugin.org.uk>uk>: Ok, my bad. 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

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

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

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

Chris Cannam wrote: 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.

On 25 Jun 2009, at 16:56, Chris Cannam wrote: 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

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

David Robillard schrieb: 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

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

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

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

Jan Weil wrote: 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

On Sun, 2009-07-05 at 19:10 +0300, Kai Vehmanen wrote: This is an error in ladspa.h 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

2009/7/6 Chris Cannam <cannam(a)all-day-breakfast.com>om>: /me quotes Chris entirely. Stefano

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

On Tue, Jul 7, 2009 at 10:56 AM, <hollunder(a)gmx.at> wrote: 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. no further comment m'lud. Chris

On Tue, Jul 7, 2009 at 12:28 PM, Steve Harris&lt;steve(a)plugin.org.uk&gt; wrote: 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... ... 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

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.