I understand the purpose of this method and the problem it is trying to solve. However…
I have a plug-in in my VST3 directory which crashes when trying to instantiate it. The scanner does not black lists this because the findDescriptionsFast does not really create an instance of the plug-in if I understand well. So the scanner thinks its ok and allows it for use in the main app. Which make me wonder what is the point of scanning on a different process if its very unlikely the plug-in to cause a crash since it does not instantiated.
findDescriptionsFast is using the ModuleInfo.json file that some plugins provide. If that file is not provided, the wrapper would have to spawn the plugin to find out which components it holds.
Also, if you scan in another process you can still add the crashed plugin to the blacklist using addToBlacklist or applyBlacklistingsFromDeadMansPedal after your ChildProcess returns with a few crashes.
Thanks for your reply but I feel I got misunderstood.
The point is that because findDescriptionsFast is using the modleinfo.json, it will allow plug-ins to “pass” the scanning process while if not using the findDescriptionsFast and try load it “slow” it can crash and be black listed. I show this behavior with a plug-in of mine which the scanner let it pass and when trying to use it in the app, it was crashing.
That is why I said do we want speed (read the plug-ins fast and do not care if they will crash or not) or robustness? The code currently in juce does not give you that option it will always try the fast before the slow…
Many plugins would not crash the scan (even with the “slow” scan) but then crash on load.
All scanning in another process is protecting you from is crash during scan. The ‘speed’ here in fast mode is still better - you might not blacklist crashing plugins that already have the module.json but it’s also likely the users won’t even try to load those plugins, and the experience of faster scan is usually better for them.
If you want to protect your host from other crashes, you can load the plugin in another process when the user is actually using it. This is something quite a few hosts are offering right now, for example Reaper, Logic and Bitwig - this would be the more ‘robust’ way to protect your users from crashes in 3rd party code.
I understand your point of view and I tend to agree. Why sacrifice speed if it can crash anyway?
Thanks for your reply, much appreciated. I will investigate loading the plug-in on different process
