Hi everyone!
I’m developing native VST audio plugin in Linux, and I want to use Ardour as host. I put my compiled plugin into ~/vst, added that path to Ardour’s VST search path. During re-scanning, Ardour listed my plugin in the pop up window, but I cannot find it in “Add Track/Bus/VCA” dialog.
I want to know whether Ardour actually validated my plugin. So is there any list file or plugin manager that I can read all Ardour plugin’s status?
When scanning, I think ardour just shows the names of the files it is scanning, so, by the sound of it ardour found your plugin.so file, but for some reason it didn’t validate. Ardour should validate just about anything that doesn’t actually crash - and most often your best bet to find out what is going on is to put some debug in the plug-in itself (if you start ardour from a terminal, even something as simple as a ‘printf’ in the plug-in will normally dump some terminal output that you can use - note that this may not be true for other hosts, especially bitwig which runs the plug-in in a separate process, which makes getting debug info directly from the plug-in a few stages more complicated). Common reasons for plug-ins failing to validate are things like wrong architecture (e.g. 32 vs 64Bit) , so always check that first.
If a plug-in has failed validation you may need to clear ardour’s black-list - and there is a long standing bug, which means that if you have installed a plug-in, and you then replace it with a newer (as in more recently compiled) version, ardour will fail to find it, because it will realise the old version was scanned, notice the new one is newer, realise the new one hasn’t been scanned, fail to scan it, and then (unsurprisingly) it won’t show up because it hasn’t been scanned.
There’s an option “Always scan for (new) plugins” which should address that.
Linux?
LD_LIBRARY_PATH=/opt/Ardour-5.10.0/lib/ /opt/Ardour-5.10.0/lib/ardour-vst-scanner -f /path/to/your/vst.so
does trigger a re-scan (-f to force a re-scan, ignoring the blacklist).
Ardour does extract the plugin’s meta-data (ports, etc) to ~/.cache/ardour5/ for later use, so that there is no need to instantiate the plugin later to get this information.
The same method works on other OS, different paths.
Ardour assumes a plugin is outdated if the file-modification time of the cache file is older than the plugin’s .so. A re-scan (manually or automatic) is needed in that case for the plugin to be available again. This is not a bug, it is intentional.
Ardour assumes a plugin is outdated if the file-modification time of the cache file is older than the plugin's .soAnd in that eventuality, ardour behaves as if the plugin simply 'doesn't exist' which causes problems loading an existing session and erroneous error messages. Doing a manual scan, or enabling scanning at startup will 'fix' the issue - but that's not the default behaviour (and irrespective of that, no other DAW I've ever used behaves this way).
This is not a bug, it is intentional.Seems like a 'fake feature' - to use the language of our time... Would it not make more sense for ardour to transparently rescan a plug-in if it determines it's 'outdated' ? - this is what other DAWs do.
Because we suffer from comments about plugin compatibility in a way that proprietary DAWs so do not. When doing a plugin scan crashes the program, people blame us. So we don’t so scans unless the user tells us to.
I wonder. The temptation for the user to blame the program he sees crashing should be just the same if the DAW is proprietary. No one wants to make you suffer. Why not accept it as a part of the linux game that one fares best if he’s ready to help solving (as opposed to avoiding) problems he hasn’t caused, unjust as it may seem? To phrase it positively, there’s a huge potential of synergies between well established ardour and the rest of the free linux audio ecosystem that I would love to see flourish.
@paul: isn’t plug-in scanning now done in a separate process precisely to avoid those crashes?
(unfortunately there are always going to be plug-ins which crash and there are always going to be host appllications which crash, the reason I’m highlighting the issue here is to try to make ardour’s behaviour better - perhaps if I show an example it will help to illustrate the problem)
I Install ardour from ardour.org - don’t change the default settings.
I build my-new-plugin.so and put it in one of the default paths.
Start ardour
Plug-in does not appear - I spend some time trying to figure out what I’ve done wrong, since the same plug-in appears to work in all the other hosts I’ve tried - then by chance I notice that I have to manually scan the plug-ins, but this is not very discoverable.
Now my new plug-in appears, but I notice I’ve made an error in my code, so I save the project, correct my mistake and rebuild the plug-in.
I copy my-new-plugin.so to the plug-ins folder, overwriting the previous incarnation.
I start ardour, load the project back so I can see if I’ve fixed the problem.
I get a warning message from ardour saying ‘my-new-plugin’ cannot be found.
I spend a lot of time trying to debug my code, wondering how a simple change could have made my plugin suddenly fail to load at all… Until by chance I realise that I need to manually rescan again…
I can fix the issue by enabling scanning at start-up, but the path to that point hasn’t been very intuitive. And the fact that ardour emits a warning saying the plug-in can’t be found is a bit misleading. This is probably a use case that mostly affects developers (unless they know about it, which is why I mention it in this thread). But, I have had to deal with occasional support issues from users who have updated to a new or bug-fix release of a plug-in and then assume I am at fault when the new version doesn’t show up.
The example is very developer centric. Users in general have lots of plugins in various places and scanning can take minutes [1]. Also most users never update plugins [2].
As for developers, compiling and test-running, you do have a point that the GUI workflow and defaults are far from ideal. However, I do suggest to run the ardour-vst-scanner after compilation is complete. It should be trivial to even do that automatically (it exits with an error code if there’s a failure) as part of step (2). That way you don’t even need to launch Ardour, no mouse-clicking to get some initial feedback if the plugin would load. Turnaround time should be a lot shorter as well. Writing a small shell script that compiles, copies the plugin, runs the scanner and launches Ardour (provide session as argument) should be trivial.
If you do have any suggestion how to streamline this further and aid plugin-developers and plugin-vendors, please don’t hesitate to let us know.
One idea is to (A) always scan VST plugins, but (B) do it non-blocking in the background, yet © check plugins used in the current session first and (D) wait for them before
loading the session. As easy as it sounds, this is a lot of work though with many edge-cases for very little benefit and VST specific (AU, LV2 don’t need to be loaded to discover parameters and I/O config).
[1] usually because of license checks, e.g. test loading each plugin in the waves-shell, every plugin checking its license can in total take 5 minutes alone.
[2] The complaints about long startup time were an order of magnitude higher compared to those users who do update plugins and can’t read the Log:
[WARNING]: Ignored VST plugin which is newer than cache: …
[INFO]: Re-Scan Plugins (Preferences > Plugins) to update the cache, also make sure your system-time is set correctly.