sorry for the title… its hard to summarize
i used Ardour Ardour-5.8.0-x86_64 on an Debian 9 installation.
I now installed Ardour-5.10.0-x86_64 and Debian testing on my new laptop.
in some old projects i used the IR reverb plugin. if i load old project on the new installation ardour says that the plugin is not found. but the plugin is installed (at the same location as on the old installation (/usr/lib/lv2/ir.lv2/)) and i can select the plugin in ardour. but all IR plugins that where already saved in the project are not working (just that dummy plugin)
i could just delete the dummy IR plugin and add it again. but then i would loose all the plugin settings.
The IR plugin recently changed its unique id from http://factorial.hu/plugins/lv2/ir to http://tomszilagyi.github.io/plugins/lv2/ir.
That URL is what identifies LV2 plugins for the host, so you should (after making a backup) replace the old URL with the new one in the ardour session file, the one with .ardour extension.
This sort of thing is really, really bad. Plugin authors should either (a) use a URI that does not resolve to an actual URL, and keep it constant or (b) ensure that the URL they use as the URI will never, ever need to change. “I no longer work there”, “I got a new domain name” etc. are not excuses. Tying a plugin to github.io is also a terrible idea.
The real problem is that LV2 uses a URI, (and, coupled with the general lack of clear documentation, it’s not always apparent to new developers what the exact purpose of that URI is, hence they may assume a requirement for an actual URL). VST3 for example uses a GUID scheme to identify the plug-in. That way the developer just generates the necessary GUID(s) as required when they first create their plug-in. The same issue would arise if they changed the GUID, but they don’t because its purpose is both documented in the SDK and obvious.
Having the URI of a plugin pointing at a real existing web presence is nice for documentation purposes. But once chosen, it must not be changed, of course.
But not everybody has a permanent web presence, so in those cases it is better to use a random URI, indeed .
Small shell oneliner to create a random URI prefix for a new plugin bundle
echo “@prefix mybundle: <urn:uuid:$(uuidgen -r)#> .”
@prefix mybundle: <urn:uuid:0b68517a-eb89-4dd5-95cf-a74151a4a774#>.
Having the URI of a plugin pointing at a real existing web presence is nice for documentation purposes. But once chosen, it must not be changed, of course...
Yes, but like all documentation, only
if it is up to date - which, of course, in many cases directly conflicts with the requirement that it not be changed... As illustrated the URI can by definition be anything unique, so a GUID makes more sense - unfortunately, precisely because it can
be anything, a lot of developers follow existing examples and are lead to the conclusion that it must
be a real URL. The real design flaw is that the (LV2) plug-in standard / format / documentation / examples or whatever leads developers to exactly the wrong way of doing things.
For the purpose of identifying a plugin, there is no semantic difference between this string of bytes - http://whatever.com/blah/blah/blah - and this string of bytes - 882a9d-efc28-2ac430e-02a
Both are intended to act as unique identifiers, and as such should not be changed if the plugin has not changed.
Although there are indeed issues with the takeaway lessons that some or even many developers seem to derive from LV2 docs and API, that doesn’t imply some general “design flaw” (boy, you do just love to carp on about LV2 don’t you) and it doesn’t mean that URIs are worse than a GUID.
Although there are indeed issues with the takeaway lessons that some or even many developers seem to derive from LV2 docs and API, that doesn't imply some general "design flaw"
A good API, is one that is usable and intuitive, that’s a part of the design. For example, the JACK API is an example of a well designed API which doesn’t generally get in the way of what the developer wants to do, meaning that the developer can concentrate on his code. LV2 isn’t.
(boy, you do just love to carp on about LV2 don't you)
Well, apart from the comments I’ve just made, I think my line on LV2 has generally been that on balance it’s no better than any other plug-in format, and you’ll likely find examples where I’ve been critical about some of those too. But, if you want me to justify my position, you should consider that you actually have far better support for a far wider range of professional plug-ins in Ardour, and therefore probably a whole lot more users, since it got VST support, than you did with LV2.
We had VST support before LV2 support … if you mean LinuxVST then yes, sure.
But LV2 allows us (and others) to do things with plugins that we could never do with VST, in a clear, documented, “standard” way. So there are always pros and cons. Given that VST3 still has no OS X/MacOS conformant way of doing plugin GUIs, claiming that it just allows the developer to “get on with it” can be a bit misleading (VST4 finally corrects this, but how many VST4 plugins are there). Should a developer follow Reaper’s convention for this? Just cast a void* to an NSView*, etc. etc. etc.
Given that VST3 still has no OS X/MacOS conformant way of doing plugin GUIs,..
VST3 does - as far as UIs are concerned, VST3 as a 'standard' is essentially agnostic, but the implementation inevitably becomes system specific at some
level, just as it does with LV2. On Mac / OS X this means an NSView, on Windows its an HWND, and on linux it's an X Window. The abstraction is completely extensible.
The last time I saw the VST3 spec they were still using a Carbon window for the plugin, not NSView. I guess they finally updated it.