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
Tue, 2024-06-11 - 09:59 Permalink
I now had a look into the code. The only condition that causes a VST3 to be rescanned is a changed modification date of the bundle directory (the *.vst3 at the top).
In fact, it is also rescanned with a moduleinfo.json present, only so much faster that you don't notice.
Some DAW probably touches this directory in a way that changes the modification date. If you can confirm that the modification date indeed changes, we will know more.
Tue, 2024-06-11 - 22:56 Permalink
Hi Andre, thanks for looking at this and confirming what the code is up to. I'm afraid my testing shows something different going on though.
I've narrowed my testing down to one VST3 plugin where I can create this behaviour on demand, here's what I've checked:
Bundle folder created / modified date, hasn't changed since the plugin was last updated:
I run an 'Update or Continue' scan using Scanner.exe results in a dialogue popping up saying 'Scanning 1 of 1' and is lists VCV Rack - I've tried to take a screenshot but it's too quick.
The below screenshot shows both the output of scanner.log and also the associated detail recorded in ScannedPlugins64.xml
I can run this as many times as I want and always get the same 1 plugin scanning with the infoUpdateTime being the only thing updated as far as I can tell. scanner.log always lists the same information too.
If I then add the Resources folder to the bundle and add the moduleinfo.json file and run another scan it gets detected again once and once only. Once the scan is done, a scanner.log file doesn't even get created when running subsequent scans so it does look like it's not re-scanning.
I have just noticed something though, here's a file compare of the ScannedPlugins64.xml before (left) and after (right) adding the moduleinfo.json file:
It looks like having the moduleinfo.json file in place causes the plugin to get listed twice, one having the path of the bundle folder, the other showing the full path to the actual plugin. The way the compare tool has highlighted it is a bit weird I'm afraid but it shows what's happened.
BTW, that's not limited to one plugin, here's another one that I'm using the same 'fix' for, same behaviour, it used to be listed once (and re-scanning constantly) until I added the moduleinfo.json file and then it's stopped being reported:
Hope that gives you something to go on, very strange indeed.
Wed, 2024-06-12 - 10:10 Permalink
Thank you very much for the detailed examination. We were unable to reproduce this yet. This will certainly help.
I checked the scanning code and it stops at the top-level VCV Rack 2.vst3 directory and does not look any further inside Contents. So how is it possible that a duplicate instance turns up? Since this is not the case with all VST3 plug-ins, some of them seem to report two instances in error.
We could simply ignore those inner duplicates (as a workaround), but ultimately this is an issue with the plug-in that needs to be fixed.
Wed, 2024-06-12 - 11:57 Permalink
To be clear, the duplicate entry only happens after I add my own moduleinfo.json file.
I didn't think to check last night, but I'm now wondering what would happen if I removed all references to the plugin from the ScannedPluginx64.xml before adding moduleinfo.json to see if that changes behaviour.
It's definitely something to do with how bundles are being interpreted, just not sure what or why.
Will do some more testing and let you know.
Wed, 2024-06-12 - 21:55 Permalink
Thanks Andre, much appreciated. I've updated to the latest build, undone my workaround and run a full rescan and can confirm I'm no longer experiencing rescan issues on any of my plugins.
Wed, 2024-06-12 - 23:40 Permalink
On windows, the easiest way I've found is to close Synfire and then go to:
C:\Program Files\Cognitone\Audio
In that folder, run scanner.exe which will pop up a window that looks like the below.
In the dropdown select 'Scan All (Reset)' then click Start.