Posted
I am evaluating the Synfire demo and am seeing a possible issue with Synfire 2 (latest build as of last night) where it seems to scan/rescan some, but not all plugins on every start up.
In addition, I've noticed that that the scan seems to flip flop between the same few VSTs / VST3s. So on one start it will do VSTs and then the next it will do VST3s, starting the app again, it will go back to VSTs.
I repeated this behaviour quite a few times last night trying to work things out but didn't get very far. Any logs I can check or any idea what might be the cause?
I'm running Windows 11 and have tried checking other related posts around rescanning etc.
Thanks in advance.
Wed, 2024-02-28 - 19:13 Permalink
A log is saved in C:\Users\(username)\AppData\Roaming\Cognitone\Temp\Scanner.log
Wed, 2024-05-15 - 14:05 Permalink
Hi.
I too see Synfire scan many plugins each time I open it, and it takes quite a long time. I would like to get past this.
I've read the solution page referenced above, and I am not really clear on how to simply tell Synfire:
Do not Scan (i.e. Ignore) this plugin
Can Synfire be instructed specifically to ignore a plugin?
Does the process to 'Enforce The Default Channel Layout' actually result in ignoring the plugin?
Wed, 2024-05-15 - 23:24 Permalink
I think there may be a bug.
BrokenPlugins64.txt, if/when populated, does seem to prevent the listed plugins from being rescanned. Good!
However, It seems as if this file is being mistakenly cleared on every other run of the program (or maybe it is when no new brokens are found to add to the list).
This of course will result in the broken plugins being rescanned again after every such clearing.
This starts the cycle over again, and that seems to be why I've not so far been able to get a nice, fast, stable load of plugins.
Thu, 2024-05-16 - 11:33 Permalink
OK.
I see more info about BannedPlugins64 here:
https://users.cognitone.com/solution/some-plug-ins-are-blocking-scan
This should be helpful, I will try to work with it.
Still though, what is the point of the way things are now?
Should not the system, once it detects a broken/unusable plugin remember that fact on it's own?
I'd think the proper role for the user would only be to do a hand edit in order to force the system to try again on a previously marked broken/banned plugin.
BTW, all observations by me above are simply wrt. launching the program. I am not explicitly taking any action to command a "reset". (but maybe I'm overlooking some checkbox?)
Thu, 2024-05-16 - 20:34 Permalink
Reality is more complex. Broken is not necessarily broken. Sometimes a re-install makes a plugin work again. Logic Pro and other DAW run a separate plug-in manager for the user to take control over each individual plug-in's scan results.
I have no idea why some VST3 or VST are scanned at every start. This shouldn't be unless the files have been touched and their names, dates or sizes changed.
One user fixed this by adding manifests to VST3 plugins that are lacking one. There's a Steinberg tool for that purpose.
Thu, 2024-05-16 - 23:13 Permalink
As Andre mentions, I worked out that all of the plugins I was having issues with were VST3s. Specifically, VST3s that follow the newer bundle format but don't include a moduleinfo.json file. I stopped the rescanning by creating the missing files using moduleinfotool.exe from the Steinberg SDK.
I didn't post anything here at the time as It's a bit technical, but if this is causing other users issues I'm happy to share my notes once I'm at my PC, tomorrow or over the weekend.
Andre, last time I emailed, you were going to follow this up with the JUCE community, have you had a chance to do that at all? I'm happy to if not, but I'll get stuck quickly if they start getting technical, I'm not a C++ developer.
Fri, 2024-05-17 - 00:07 Permalink
all of the plugins I was having issues with were VST3s. Specifically, VST3s that follow the newer bundle format but don't include a moduleinfo.json file
Is this situation detectable by the scanner?
If it were logged, we could advise the plugin's developer and maybe they would attend to the issue.
OTOH, maybe they wouldn't.
So, knowing how to fix it in the field would be valuable.
BTW, I notice that many/most of the constant re-runners are actually Steinberg plugins!
Fri, 2024-05-17 - 03:49 Permalink
BTW, I notice that many/most of the constant re-runners are actually Steinberg plugins!
I'm no expert but I understand that most Steinberg native plugins (ie FX in Cubase, Wavelab, Dorico etc) can't be used in other hosts. Instruments are mixed ... the free Halion Sonic 7 is ok as are other paid instruments but some that come with the main apps eg Groove Agent SE aren't.
Fri, 2024-05-17 - 09:50 Permalink
Thanks for sharing your solution.
We first need to debug what exactly causes the rescans before checking with the JUCE community. Cognitone built its own management layer on top of JUCE, so chances are it's our own fault.
Changing the code to ignore a missing module info (instead of assuming it's outdated) may fix this.
Fri, 2024-05-17 - 22:50 Permalink
Here is my notes on how I resolved the rescanning issues affecting VST3s following the bundle format, but not having a modueinfo.json file. This solution isn't going to be for everyone, like I said, it's a bit involved, so if you're not comfortable with any of the below I would advise against it so you don't break anything, but it helped me greatly reduce load times for Synfire.
The following solution works for me with the current version of Synfire Pro as of 2024-05-07. The below was done on a machine using Windows 11 as I'm a Windows user, I have no idea if this is a problem for Apple users.
VST3 Bundles can be determined by the following type of directory structure where you have a vst3 file buried in a structure that starts with a folder of the same name, below are two examples:C:\Program Files\Common Files\VST3\Steinberg\HALion 7.vst3\Contents\x86_64-win\HALion 7.vs3C:\Program Files\Common Files\VST3\RYM2612.vst3\Contents\x86_64-win\RYM2612.vst3
Within this structure, there may or may not be a Resources directory under Contents alongside x86_64-win directory:C:\Program Files\Common Files\VST3\Steinberg\HALion 7.vst3\Contents\Resources
This directory may or may not include the moduleinfo.json file. If the Resources directory exists already and there is a moduleinfo.json file already then these steps won't help and there is probably a different issue.
Halion 7 is an example of a plugin that has the Resources directory but no moduleinfo.json, RYM2612 does not even have the Resources directory, for those that didn't have it, I created a Resources directory as above as it is needed to put the modueinfo.json into.
The process requires the Steinberg SDK to be built from source. To do that I installed Visual Studio 2022 Community Edition with the 'Desktop development with C++' workflow selected, this installs all of the tools required including cmake which Steinberg say install separately, no need to do that as the above installs it.
Full SDK documentation is here, it mentions about Windows needing changes for symbolic links, I ignored that as there is a flag that can be used so that's not necessary. Once the SDK is downloaded and the examples built as detailed here the moduleinfotool.exe will exist, in my case in C:\DevTools\vst-sdk_3.7.10_build-14_2024-01-18\VST_SDK\build\bin\Debug
If you're still reading, once the SDK examples are built, the rest of the process is easy, using moduleinfotool.exe you can create moduleinfo.json files.
Open a CMD window and navigate to where moduleinfotool.exe was created, then from there run the following command against the plugin you want to create a moduleinfo.json file for:moduleinfotool.exe -create -version 1.0.0 -path "C:\Program Files\Common Files\VST3\Steinberg\HALion 7.vst3\Contents\x86_64-win\HALion 7.vst3" -output "C:\Program Files\Common Files\VST3\Steinberg\HALion 7.vst3\Contents\Resources\moduleinfo.json"
Two parts of this needs to be updated, the first to the plugin itself and then the second to where the moduleinfo.json should be created.
Finally, using your text editor of choice, open the moduleinfo.json that is created above and edit the Name and Version found at the very top of the file - The values to update them with are a few lines lower down
If it's worked, next time you start Synfire it will scan but that will be the last time until something changes.
Please be careful though, I don't want to be responsible for breaking plugins, this worked for me and I haven't noticed any issues in the plugins themselves or in other DAWs but obviously it doesn't come recommended from Cognitone or any of the plugin vendors.
Fri, 2024-05-17 - 22:53 Permalink
We first need to debug what exactly causes the rescans before checking with the JUCE community. Cognitone built its own management layer on top of JUCE, so chances are it's our own fault.
Andre, if I can be of assistance with that in terms of running debug builds etc please let me know, I'd be happy to help and I've got quite a few VSTs that trigger this behaviour.
Sat, 2024-05-18 - 10:54 Permalink
Thanks for sharing your solution. It is more involved than expected.
Synfire should probably not silently alter a user's installed plugin bundles this way. So our best bet is to simply ignore the module info if it can not be found. Can't promise an ETA for a fix, but at least the cause seems evident now.
Sat, 2024-05-18 - 12:41 Permalink
Synfire should probably not silently alter a user's installed plugin bundles this way. So our best bet is to simply ignore the module info if it can not be found.
I agree, I was never suggesting this as a viable solution long term, it is just the workaround I am using until the behaviour can be corrected which may be of use if a fix takes a while as I was getting frustrated with how long the scan was taking.
Ultimately I would like to undo the changes I've made once resolved.
Interestingly, Steinberg say this is optional anyway and the location of the file has moved over time too, so it does appear Synfire is being overly strict. Source