FJ Lamela Posted February 8, 2020 Share Posted February 8, 2020 I have the same problem as you! Dont know what's happened. Today the plugin scanner dont show or recognize 32bit plugins A problem?,a windows10 problem? Link to comment Share on other sites More sharing options...
Robert Bone Posted February 8, 2020 Author Share Posted February 8, 2020 2 hours ago, FJ Lamela said: I have the same problem as you! Dont know what's happened. Today the plugin scanner dont show or recognize 32bit plugins A problem?,a windows10 problem? Still working on figuring it out. I will post updates shortly. Bob Bone Link to comment Share on other sites More sharing options...
FJ Lamela Posted February 8, 2020 Share Posted February 8, 2020 Thank you Link to comment Share on other sites More sharing options...
Robert Bone Posted February 8, 2020 Author Share Posted February 8, 2020 Just now, FJ Lamela said: Thank you Sure - I know with certainty that I had done nothing that would have caused this situation to appear - meaning that I had made ZERO changes to my small number of 32-bit plugins I still must hang on to,. I discovered the issue when I loaded a recent project that used a couple of the 32-bit plugins, and during the load, a popup message box was displayed, saying that those plugins were referenced by the project, but could not be located. Sure enough, ALL of my 3rd-party 32-bit plugins (I had 10 of them), had completely vanished from the inventory CbB builds when it does a VST plugin scan. Worse than that - they were not excluded. It was, rather, that they were not even processed by the Cakewalk Plugin Manager, DESPITE the path to those 10 plugins being unchanged, and present in the VST Scan Paths that Preferences and the Plugin Manager use for scanning to build the inventory of viable plugins. So - they were NOT found to be problematic and excluded. Nope. They were not even processed by the VST scan. I know this because I checked the box to force it to generate a scan log, and in the logs, the only thing present that dealt with those ten 32-bit plugins, was a single reference to the VST scan path I had added, as the scan log lists out all of the VST scan paths it will be evaluating. The PROBLEM is that nothing whatsoever appears in the scan log after the simple listing of that path - so the Cakewalk Plugin Manager has suddenly stopped even looking at 3rd-party 32-bit plugin paths, so those plugins never then show up in the post-scan VST inventory of plugins available for use in CbB, and again, they are not present as Excluded either - it just simply never looked at any of them. SOOOOOOOOOOOOO - I have gone into "Kill it Dead Mode", where I uninstalled CbB, and jBridge, and additionally went into AppData, Program Data, and the Registry, to completely eradicate any traces of both CbB and jBridge, (other than leaving the parameter in every single Inventory Registry entry for every valid plugin in the inventory, that tells CbB whether or not each plugin is to use the jBridge Wrapper to load that plugin (it is built in to CbB so I did not disturb that, but every single occurrence of that parameter - which is part of each plugin's data in the CbB plugin inventory, each data value for that jBridger Wrapper parameter was set to binary zeroes - meaning no plugin is set to be loaded through jBridge). I have just reinstalled CbB, and have NOT yet installed jBridge again, so as to leave this as a completely CbB ONLY scenario, so that jBridge is not part of this current set of testing I will be performing shortly. I want to first make sure I can get the Cakewalk Plugin Manager to even process a single 3rd-party 32-bit plugin that I KNOW was working prior to this glorious nightmare. Mike (CbB support staff @msmcleod) had earlier suggest that there might be an issue with one or more of those 32-bit plugins, and that I try adding those back into the VST search path's folder for the 32-bit plugins to be scanned by the Plugin Manager, so that IF that was the issue, that doing them one at a time would expose which one(s) was/were problematic. This is what I am about to try doing, to see if ANY of my ten 32-bit 3rd-party VST plugins can be successfully scanned. I do already have CbB reinstalled, and am just now about to try adding those in, one at a time, to what IS a completely default CbB install, with NO jBridge present in the system, and the only change to defaults being the addition of the empty 32-bit sub-folder that will eventually have the plugins added - one at a time. The first launch of CbB will not yet have the folder added, and when I do add that folder added - there will be nothing added, with just a restart of CbB. Then, I will close CbB, add a single 32-bit plugin that is KNOWN to work in a 64-bit CbB, and then when I launch CbB again, with loggin enabled, it should process and evaluate that plugin for successful inclusion in the VST Inventory for general use in CbB. I will update this thread as soon as I conduct those additional tests, which should not take long at all. Bob Bone 1 Link to comment Share on other sites More sharing options...
Robert Bone Posted February 9, 2020 Author Share Posted February 9, 2020 (edited) OK, somthing is BROKEN, with the Cakewalk Plugin Manager, with regard to detecting and evaluating ANY 32-bit 3rd-party plugins, during a VST scan. VST Scan DOES detect the VST scan path that points to the folder where a single 32-bit plugin was added, and that plugin worked for several years, and is NOT in the excluded plugins, in any category. The number of reported plugins found SHOULD have gone up by 1, after I launched Cakewalk following the adding of that single plugin to a valid folder in the VST scan paths. When I launched CbB, it DID kick off the expected VST scan, however it reported no new plugins added or removed, and the total reported number of plugins had not changed. I suspect that in this latest release - something connected to the work/mods done to the VST Scan program, where it now will no longer scan the Common Files VST3 folder for any VST2 plugins - I believe something connected to that maintenance has 'broken' the scanning process for 32-bit 3rd-party plugins, and it is that feature modification that is at the root of not only MY current issues with this, but also with the same issue, as reported by @FJ Lamelaearlier in this thread. Neither FJ or me had done ANY modifications to the VST scan paths, prior to this issue showing up. This is MASSIVELY affecting the current project I am working on, that had a deliverable of yesterday morning, and is quickly becoming a bad situation, as it affects the deadlines of other folks in the chain that are waiting for me to finish work on the project and send it along to them. SO - please please please please please, @msmcleod, or @Noel Borthwick, or anybody else - please please please please look into this with me, for me, because of me, in spite of me - or any of those to help me get the ability to use the few 32-bit plugins I still have to use. jBridge is no longer present on my system, BitBridge is not being used for the single 32-bit 3rd-party plugin I am attempting to have properly get added to the VST inventory, and I am running patch current Windows 10 Professional, and a squeaky-clean fresh install of Cakewalk by Bandlab current version (2020.01 Build 24) I also tried creating a new 32-bit folder and placing that single plugin there, and added that path to the VST Scan Paths in Preferences. The rescan took place, but again that plugin was not even evaluated, though it did detect the folder addition to the scan paths. The last attempt was to remove that path, and then I coped that single plugin to an existing path - the one for Cakewalk Sound Center, and it did kick off the VST scan, so it knows something changed, however there is zero presence of any evaluation in the scan log for that plugin. Lastly - because the Cakewalk Plugin Manager is shared with Sonar Platinum, I cannot simply attempt to finish up my work in Sonar Platinum either, as the plugins are not detected there, either. Thanks EDITED BIG CLUE: OK so, I just ran a 2nd test in Sonar Platinum, THIS time, I moved the single 32-bit 3rd-party plugin into a newly-created folder in my VST64 folder which is in Program Files and not in Program Files (x*86), and is the folder I created years back, to house all of my VST2 64-bit plugins. It did not kick off an automatic scan - but I might not have waited long enough before restarting Sonar Platinum, but in any case, THIS time, in Sonar Platinum, the 3rd-party 32-bit plugin DID get processed, and the VST Scan Toaster message DID indicate it found 1 new plugin, and sure enough, it is showing up in the inventory display for VSTi in Cakewalk Plugin Manager. SOOOO - the big clue is that somehow, something broke the processing logic in Cakewalk Plugin Manager, where it simply does not bother with evaluating any 3rd-party 32-bit plugins contained in any sub-folder within Program Files (x86), but the logic DOES work properly, when 32-bit 3rd-party plugins are located in a sub-folder of the 64-bit Program Files folder. I will test this out in CbB, which should now properly pick up that same plugin, as my VST64 sub-folder in Program Files is in the VST scan paths for Preferences and the Cakewalk Plugin Manager, and if indeed that now works, as expected to, I will then add in the rest of the 9 other 32-bit plugins, and leave them there, until such time as the Cakewalk Plugin Manager logic gets fixed again. Unless I post of this not working, as my workaround, I should be able to get back to working on the deliverable that was due yesterday, and at least have a way to accomplish my work while waiting for the actual corrective fix. I hope the above BIG CLUE explanation gives a developer enough of where to look at the logic of the Cakewalk Plugin Manager to quickly address the currently and recently broken evaluation logic. And, @FJ Lamela - if you temporarily move your 32-bit 3rd-party plugins OUT of the Program Files (x86) folder, and INTO the 64-bit Program Files folder (in some sub-folder within your already being scanned folder for your 64-bit VST plugins), you too should be, in theory, also back in business, while we wait for a permanent solution to this issue. Bob Bone Edited February 9, 2020 by Robert Bone Added BIG CLUE text to explain some workaround progress I have made Link to comment Share on other sites More sharing options...
scook Posted February 9, 2020 Share Posted February 9, 2020 Probably no need to physically move the plug-ins. A directory junction in the 64bit path pointing to the 32bit path should work. Running as administrators open a command shell and type mklink /j "C:\Program Files\Cakewalk\Vstplugins\32bitPath" <enter the real 32bit path here> Name "C:\Program Files\Cakewalk\Vstplugins\32bitPath" what ever you want in the current 64 bit path Link to comment Share on other sites More sharing options...
msmcleod Posted February 9, 2020 Share Posted February 9, 2020 @Robert Bone - The fact that plugins aren't picked up within C:\Program Files (x86)\ by Cakewalk Plugin Manager, but they are within SONAR to me sounds like it could a permissions issue (possibly caused by a Windows update?). If you run the scan from directly within CbB's Preferences->VST Settings does it pick it up? Follow-up: - I've just tried scanning a 32 bit plugin in C:\Program Files (x86)\vstplugins using Cakewalk Plugin Manager. It appeared to scan it, but was no where to be found. I then removed the plugin, and re-scanned using CbB's Preferences page. I put the plugin back into C:\Program Files (x86)\vstplugins, and scanned again using CbB's Preferences page. This time it was picked up. So it does look like there might be an issue with Plugin Manager and scanning C:\Program Files (x86)\ (however, I did notice I had other files in my directory which could be causing the issue). My recommendation would be to always use CbB's Preferences page to do your scans, if nothing else but for the fact it does a sandbox scan which prevents the scan from aborting should it encounter an issue - but at least do it this way for the meantime until the problem within Cakewalk Plugin Manager is identified/resolved. 1 Link to comment Share on other sites More sharing options...
scook Posted February 9, 2020 Share Posted February 9, 2020 5 minutes ago, msmcleod said: My recommendation would be to always use CbB's Preferences page to do your scans Noel has been recommending this for years It may be time to disable the scanner in the PIM when running CbB. 1 1 Link to comment Share on other sites More sharing options...
Robert Bone Posted February 9, 2020 Author Share Posted February 9, 2020 Never had an issue before, but certainly I will be using Preferences from now on, for the sandbox, and for the option for logs. And, I am not sure how you determined that it actually did scan the plugins, because other than the initial listing of the path in the VST Scan Paths, there is ZERO additional reference to any of the plugins in the logs, when those plugins are in a 32-bit folder. Bob Bone 1 Link to comment Share on other sites More sharing options...
Robert Bone Posted February 9, 2020 Author Share Posted February 9, 2020 Thanks for jumping into the thread to help me, by the way. GREATYLY appreciated. 1 Link to comment Share on other sites More sharing options...
FJ Lamela Posted February 9, 2020 Share Posted February 9, 2020 @Robert Bone thanks for your help and work. I can confirm is a bug in last release. 2019.12. build 26 works perfect. This a problem in 2020.01 only. I hope the bandlab cakewalk team fix it! Thanks! 1 Link to comment Share on other sites More sharing options...
Noel Borthwick Posted February 9, 2020 Share Posted February 9, 2020 There have been no changes to Plug-in manager recently. All it does is utilize the VST scanner for scanning but as has been mentioned numerous times, all scanning should be done from Cakewalk not plugin manager. We don't maintain or test scanning from plug-in manager and the scan functionality from there will be removed soon. There are many other improvements to scanning such as sandbox scanning that are only available from the Cakewalk preferences dialog. We'll look into why this happened but please use the standard preferences page for scanning, which has been the preferred way to do it for many years. 1 Link to comment Share on other sites More sharing options...
Canopus Posted February 9, 2020 Share Posted February 9, 2020 20 minutes ago, Noel Borthwick said: We don't maintain or test scanning from plug-in manager and the scan functionality from there will be removed soon. So taking the improved VST scan code in Preferences and put it in the Plug-in Manager is not an option? Why not? Obviously, the program code already exists. Link to comment Share on other sites More sharing options...
FJ Lamela Posted February 9, 2020 Share Posted February 9, 2020 (edited) 51 minutes ago, Noel Borthwick said: There have been no changes to Plug-in manager recently. All it does is utilize the VST scanner for scanning but as has been mentioned numerous times, all scanning should be done from Cakewalk not plugin manager. We don't maintain or test scanning from plug-in manager and the scan functionality from there will be removed soon. There are many other improvements to scanning such as sandbox scanning that are only available from the Cakewalk preferences dialog. We'll look into why this happened but please use the standard preferences page for scanning, which has been the preferred way to do it for many years. Hi Noel,i can cofirm something is broke.I've made this test. I install 2019.12. build 26 and i Make a a scanning from cakewalk (not plugin manager).all my 32 bits plugins (inside c:/vst32/) are detected.Works perfect. I install 2020.01 build 24 and make the same,scanning from cakewalk (not plugin manager).Cakewalk say 321 plugins 0 add,7 removed!!!.Something dont work!. I repeated the same procedure 3 times and 3 times occurs the same problem. Thanks in advance! PD:(I dont use jbridge) Edited February 9, 2020 by FJ Lamela 1 Link to comment Share on other sites More sharing options...
Robert Bone Posted February 9, 2020 Author Share Posted February 9, 2020 34 minutes ago, Noel Borthwick said: There have been no changes to Plug-in manager recently. All it does is utilize the VST scanner for scanning but as has been mentioned numerous times, all scanning should be done from Cakewalk not plugin manager. We don't maintain or test scanning from plug-in manager and the scan functionality from there will be removed soon. There are many other improvements to scanning such as sandbox scanning that are only available from the Cakewalk preferences dialog. We'll look into why this happened but please use the standard preferences page for scanning, which has been the preferred way to do it for many years. Thanks for jumping into the thread, Noel. Couple of points: 1) I will happily use Preferences VST scanning, for the rest of time. For the record, I had never seen any recommendation to stay clear of Cakewalk Plugin Manager, except for Steve's (scook) indication that you had posted about it before - which was yesterday. Wherever and whenever it had been suggested in the past, to run scans from Preferences, I had not seen that advice. I don't doubt that advice had been given - I just had not seen it. 2) When I created this thread, I did not know that the scanning at launch wasn't being done by Cakewalk Plugin Manager, so my original reporting of scan failures should have named VST Scanning for being at fault, because my issues were caused by VST Scanner's failure to evaluate and process 3rd-party 32-bit plugins for inventory. I did understand that the scanning was kicked off as a separate process, so that CbB would continue to open while the scanning of VST plugins ran, I just did not know that wasn't the actual Cakewalk Plugin Manager doing the scanning during launch. Apologies for my not having named the correct cause of the issues I was having. When the issue first arose, it was during the launch of CbB opening a specified existing project, and in that launch, whatever had gone wrong with the VST scanning resulted in several of the previously working 32-bit plugins, that were part of the project, to be no longer 'found'. I had not run any scan from Cakewalk Plugin Manager at that point. Bob Bone 2 Link to comment Share on other sites More sharing options...
Noel Borthwick Posted February 9, 2020 Share Posted February 9, 2020 39 minutes ago, FJ Lamela said: Hi Noel,i can cofirm something is broke.I've made this test. I install 2019.12. build 26 and i Make a a scanning from cakewalk (not plugin manager).all my 32 bits plugins (inside c:/vst32/) are detected.Works perfect. I install 2020.01 build 24 and make the same,scanning from cakewalk (not plugin manager).Cakewalk say 321 plugins 0 add,7 removed!!!.Something dont work!. I repeated the same procedure 3 times and 3 times occurs the same problem. Thanks in advance! PD:(I dont use jbridge) @FJ Lamela Some questions: Are the 7 plugins removed when you scan from cakewalk the same plugins from c:/vst32/? Do any of those plug-ins reside within a folder that has the name VST3? Are the removed plugins VST2 plugins? 1 Link to comment Share on other sites More sharing options...
Robert Bone Posted February 9, 2020 Author Share Posted February 9, 2020 (edited) 11 minutes ago, Noel Borthwick said: @FJ Lamela Some questions: Are the 7 plugins removed when you scan from cakewalk the same plugins from c:/vst32/? Do any of those plug-ins reside within a folder that has the name VST3? Are the removed plugins VST2 plugins? Hey Noel - Maybe the new logic is getting a partial name match because both of our folders have VST3 in their naming (full folder names are VST32)? That might make sense, as I had tried to explain earlier, when I had my 32-bit plugins in a sub-folder to VST32, the plugins were not removed, or added, or ever mentioned in the scan logs, like they were never even considered for evaluation. And, it would be consistent with the fact that when I moved those exact plugins to a sub-folder within my 64-bit plugin folder, named VST64, that there would be no partial match on the folder name, and then it would all work as expected, showing the plugins added. Bob Bone Edited February 9, 2020 by Robert Bone Added a little more info 2 1 Link to comment Share on other sites More sharing options...
scook Posted February 9, 2020 Share Posted February 9, 2020 6 minutes ago, Robert Bone said: Hey Noel - Maybe the new logic is getting a partial name match because both of our folders have VST3 in their naming (full folder names are VST32) Ha...that seems reasonable. 1 Link to comment Share on other sites More sharing options...
FJ Lamela Posted February 9, 2020 Share Posted February 9, 2020 (edited) 3 hours ago, Noel Borthwick said: @FJ Lamela Some questions: Are the 7 plugins removed when you scan from cakewalk the same plugins from c:/vst32/? Do any of those plug-ins reside within a folder that has the name VST3? Are the removed plugins VST2 plugins? Are the 7 plugins removed when you scan from cakewalk the same plugins from c:/vst32/? Yes they are removed of listed plugins. Do any of those plug-ins reside within a folder that has the name VST3? Nope,because these plugins are 32bits and are installed only in c:/vst32/ for me (manually),no subdirs. Are the removed plugins VST2 plugins? Yes they are!effects & instruments! Thanks for your support! Edited February 9, 2020 by FJ Lamela Link to comment Share on other sites More sharing options...
User 905133 Posted February 9, 2020 Share Posted February 9, 2020 (edited) I just checked my XP SP3 PC and my Win 10 PC and can't find any folders named VST32. Is that something individual users create? something an earlier version of Cakewalk/SONAR creates? something that third-party plug-in installers create? something JBridge creates? Just wondering. FWIW, I don't see people talking about a VST32 folder here. If its something only users do, I am not worried; but if other plug-in installers do that, I want to keep an eye open for them. Thanks. Edited February 9, 2020 by User 905133 to add a link to a tangentially related discussion in the old forum Link to comment Share on other sites More sharing options...
Recommended Posts
Please sign in to comment
You will be able to leave a comment after signing in
Sign In Now