Ardour4 - plug-in scanning seems to do something very odd. It scans a VST plug-in successfully and then tells me it can’t be found on the system and will be replaced by a stub?!
(Plugin is working in other hosts on the same system)
Clearly something completely nonsensical is happening - is this a new ‘feature’ or can someone explain the sense of it to me? (and / or how to clear the cache and restore predictable behaviour)
Preferences > Plugins > Clear Cache/Blacklist
Also enable “verbose Logging” in that Preference Pane and check Window > Log.
Most likely explanation the plugin failed to load in the past and was blacklisted.
PS. How did you deduct that the VST plugin was scanned successfully? Which version of Ardour4 is that (Help > About)? Which Operating System?
@x42: Ardour4 on linux - paid for from ardour.org. Clearing the blacklist seems to have fixed it, but the message is confusing, why does it tell me it can’t be found on the system if its just blacklisted - shouldn’t it tell me its been blacklisted if its been blacklisted? (e.g. like Logic, Cubase etc do).
(I could see it was being scanned, from diagnostics in the plug-in, and it worked / scanned in other hosts)
At the point when Ardour loads the session, there’s no distinction anymore. From the “Session’s” Point of View the plugin is simply not present.
in VSTs case: the blacklist is per file (.dll or .so that failed to load), while the session has a reference to the unique VST ID. If we can’t load the dll, we can’t query the VST ID and hence we cannot deduct it that missing plugin is in the blacklist. Best we can do is amend the “missing plugin” message to hint that the plugin is not available OR was maybe blacklisted.
Then again for musicians/studio engineers this is usually pretty much never the case. Either a given .dll loads or it does (the .dll does not change.)
@x42: Changing the message to hint that the plugin might be blacklisted would be helpful - my problem was that there was nothing to tell me what had happened (I understand that my use case is somewhat unusual) - but to explain the sequence of events, here’s some context:
Firstly, I’m porting my OpenGL rendering engine to linux, so I’ve spent way more time than I should have fighting the linux graphics stack (I’m sure I don’t need to explain how uniquely unfriendly the X11 architecture is to embedded plug-in GUIs, especially when the default X behaviour is to explicitly exit the application on any error). Add to that the GLX / OpenGL layer and the complexity of different drivers / components, GLSL shader language incompatibilities and versions / extensions and its entirely possible I’ve finally gone or will go insane.
So, I had a bug which was causing a deadlock unloading the plugin, which I was trying to identify, and at some point that must have caused the plug-in to crash or timeout during scanning.
Problem was, there seemed to be no message to tell me it had happened, the first message I got was the plugin can’t be found on the system… . Even reverting to other versions wouldn’t fix it, as I now know because it had been blacklisted.
I guess I was too much destracted by obscure code issues and overlooked the obvious.
message amended: https://github.com/Ardour/ardour/commit/9c5bdc6cf - I hope that’s a sufficient enough hint for similar future cases.
As an aside: for OpenGL plugin GUIs i had the opposite experience. My thoughts on the WGL API can’t be put in writing 
GNU/Linux/X11 sucks least, though OSX isn’t bad either. But this highly depends on the personal mindset one is in when programming, I suppose.
@x42: Thanks . WRT to OpenGL, it most likely depends what you are doing, I’m not using the standard glew / glut etc convenience libraries, my experience has been that though they mostly work, if they don’t , then you just have another inaccessible problem, inside someone elses code, so I opted to build a complete UI engine from the ground up (this is not just simple glBegin / glEnd stuff, this is modern GL with programmable shaders etc). The Windows wgl API is ok - you actually need very little of it and it works. Similarly, I ported the code to Mac, and even including the extra ObjC overhead, it was fine. GLX / XLib / X11 is a different matter. Its compounded by the need to run the UI in a separate thread on its own display because this is a plug-in and on linux you don’t know what toolkit the host is using etc, plus XLib default behaviour for all errors is to quit the application. See this description of some of the issues.
http://www.remlab.net/op/xlib.shtml
In addition you have to account for all the different combinations of drivers (open source / mesa vs binary) and different hardware. It’s probably ok if you want to write something which just runs on your computer, but if you want to create an application which you can deploy on other machines its a different matter. Anyway, I believe my original problem is now fixed - and it should be clearer what is happening in Ardour now.