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.
Mi., 28.02.2024 - 19:13 Permalink
A log is saved in C:\Users\(username)\AppData\Roaming\Cognitone\Temp\Scanner.log
Mi., 15.05.2024 - 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?
Mi., 15.05.2024 - 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.
Do., 16.05.2024 - 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?)
Do., 16.05.2024 - 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.
Do., 16.05.2024 - 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.
Fr., 17.05.2024 - 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!
Fr., 17.05.2024 - 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.
Fr., 17.05.2024 - 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.