Robert Bone

Thanks for jumping into the thread to help me, by the way. GREATYLY appreciated.

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

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

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

Still working on figuring it out. I will post updates shortly. Bob Bone

OK, I will try that. If so, not very graceful exception handling.

Yes, except none of the 32-bit plugins show up, and are not even processed by the scan...nothing in log except one mention of the path to the folder they are in.

I simply can NOT get CbB to scan ANY 3rd-party 32-bit plugins. ZIP, NADA - I am beyond frustrated, and have lost an entire day, and completely missed a deliverable. The scan logs clearly showed a plain vanilla 32-bit sub-folder with the 10 such 3rd-party 32-bit plugins needed to run in CbB, in the paths (VST scan paths), and then nowhere in the remainder of the scan log is there a single mention of that path, like it just never even processed anything within it. Details to follow: After resetting and reconfiguring the situation, to where I copied the contents of that 32-bit sub-folder into a folder called 'jBridge Candidates' (I copied them into a new folder so as to keep the original plugins separate from anything jBridge might do to them). Then, I ran jBridge and configured it to process the 'jBridge Candidates' folder as the 'source folder', and then selected an empty folder called 'jBridged Plugins' for jBridge to place the files with the wrappers to run in CbB, and let jBridge do its thing, with the parameter in it set to Confirm Each File - which it did. Then, I launched CbB and ran a complete rescan of existing and and failed plugins, after 1st deleting the scan logs, so they would be nicely fresh and only containing anything from this newest scan. The complete rescan finished, and as noted above, other than the initial presence of the 32-bit sub-folder ('jBridged Plugins') in the scan log listing for the VST scan paths present for that scan, there is not one single mention again in the scan log, of anything to do with that 'jBridged Plugins' folder containing the ten 32-bit plugins I need to configure to properly run in CbB. And, repeating everything outside of using jBridge, so as to let the 32-bit plugins be managed using BitBridge, the same thing happens - in that other than the initial listing of the path of the 32-bit sub-folder, containing the ten 32-bit plugins to process, there is not one single mention of any of those ten plugins, nor is there any mention of failure - it is TRULY like the scans are not bothering to go into those sub-folders to even try to process or inventory, or fail, any of those 32-bit plugins. In my multiple decades of dealing with Sonar and now Cakewalk by Bandlab, I have NEVER encountered such a bizarre and shoot me dead in the water situation, with regard to using any 32-bit 3rd-party plugins. I don't know why this occurred in the first place, nor do I have any idea of how to resolve this situation. Please please please folks, help me sort through this, Thanks Bob Bone

@scook still no success. I have completely ripped jBridge out of the picture, and completely replaced the folder in my VST32 sub-folder that holds the small number of 32-bit plugins I need to retain, and have done a VST Reset and full scan, and later a manual full scan, and NONE of the 32-bit plugins are being detected at all - the PATH to the 32-bit sub-folder they are in exists in the scan logs, but there is NO indication of any processing of any of the plugins - only the 64-bit plugins are processed. I have now uninstalled CbB, and renamed the Core registry key, to CoreOLD, to get CbB completely out of the Registry, and am going through a reinstall of CbB and its additional add-ons, and will try again. I TRULY do not understand why this has suddenly gone belly-up like this - for the approximately 10 32-bit plugins I need to be properly detected. Bob Bone

I have never had occasion where any sort of midi bleed or errant echo has occurred between midi tracks on any of my computers, over the years, and I always have each midi track set to None (Omni), as the specification of the associated soft synth in the midi track's Output parameter sends any midi data for that midi track to that soft synth specified in the Output parameter. When the desired midi track is in focus, and/or its Midi Echo Input is On, midi data for that track is properly sent to that soft synth. If any additional midi tracks have their Midi Input Echo turned On, then with the Input set to None (Omni), then triggered notes from any midi controller will still properly be sent to each track's associated soft synth, as specified in each of those track's Output parameter. The only time I would actually specify specific midi controllers for midi tracks, is if I were to be recording multiple midi controllers at the same time, such as simultaneously wanting to record my playing perhaps strings on one midi controller, and perhaps some sort of lead sound on a different midi controller, but ONLY if I were recording myself playing both midi controllers at the same time - which for recording I pretty much would never do. There is nothing actually 'wrong' with specifying a specific midi controller in a midi track's Input parameter, I just do not find it necessary for proper recording of a single midi controller for any of my midi tracks. Bob Bone

You can alter the location of the Cakewalk Projects folder, in Preferences. 1) With Cakewalk closed, create a Cakewalk Projects folder at the location you wish, and populate it with all of the project folders from your C:\Cakewalk Projects folder. I suggest then deleting the project folders from the original C:\Cakewalk Projects folder, ONLY after you have made sure they had all properly copied over to the new location. 2) Launch Cakewalk, and Go to Edit > Preferences > File > Folder Locations, which will give you a screen with the paths to various folders of Cakewalk content, and these paths are editable. 3) Edit the path for the Cakewalk Projects folder, by browsing to its new location. 4) Click Apply when finished pointing to the new location 5) I don't recall if you then have to restart Cakewalk or not. PLEASE NOTE: Since the location of all of your projects will have moved, it may well be that Cakewalk won't find the Recent Projects that are shown on the Start Screen - but I may or may not be correct on that. (it has been a long time since I moved my projects folder). SO, don't worry if you click on a Recent Project on the Start Screen and it cannot find it - it would just mean that you would have to open it again from the list of Existing Projects - at the left side of the Start Screen, which will find all of your projects by using the new path you had specified for the Cakewalk Projects folder in Preferences. Bob Bone

Will do, thanks

Yup I knew that - and that further blows my mind, because whatever is detected or not, should be the same, between Platinum and CbB.

Not sure I understand your suggestion

And, because of jBridge potentially having an issue, I had pulled it completely out of the equation, and pointed the plugin manager to a folder containing the original 32-bit plugins, where jBridge had not processed them, and even Bitbridge still did even see those plugins, which all worked perfectly for years, being bridged. AND, Sonar Platinum's plugin manager sees all of the jBridge-processed 32-bit plugins, so it is quite strange. Bob Bone

Yup I did a full rescan, and it didn't correct the situation. I will do so again, after checking the parm to create a scan log, and look to see if there are any clues in that. Bob Bone

The above suggestion about disabling CbB's "Zero Controllers When Play Stops" behavior, deals with situations where for some reason, the instrument's volume is tied to the Mod Wheel, so when CbB zeroes out the controllers, after playback, the result for those situations is that the instrument volume goes down to nothing. In regular situations, that issue would not arise - meaning that with Zero Controllers checked, for projects where instruments do NOT have volume tied to mod wheel, there is no issue. Give the above a try, and see if it address your issues - just be aware that your controllers will all keep their last value when playback is stopped, once you remove that check for the Zero Controllers parameter. Bob Bone

Update - Pulling the jBridge Plugins folder out of the scan path, and adding in the 32-bit folder "jBridge Candidates", which has the original 32-bit plugins before jBridge processes them, CbB shows no new or removed plugins, so it looks like NONE of the 3rd-party 32-bit plugins are even seen at all - because iit didn't show either removal or addition of any, AND, nothing in the excluded folders shows up, either. It is like CbB's Plugin Manager just suddenly stopped dealing with 3rd-party 32-bit plugins altogether. Bob Bone

YIKES, a problem! I have someone waiting all day for me to complete work on project, so I have an urgent need for some assistance. My jBridged plugins no longer seem to be scanned, by Plugin Manager. They are not excluded, and not present, even though the path to them is unchanged. ( I have had jBridge for 10+ years, and even after reloading my "jBridged Plugins" folder, by having jBridge process a 'candidate' folder, I see none of them). Also, same paths in Sonar Platinum DO show my bridged plugins from the same "jBridged Plugins" folder, so jBridge seems to be working fine - in Platinum, just suddenly not in CbB. SOOOOOO, with no mention (seen by me): What changed? Why? What doI do? I have someone out of state expecting completed work from me, this morning, that I cannot deliver. Bob Bone

Yikes, on the price difference, sorry. Can you not buy one from the US and get it shipped? Where do you live?

Thanks - I added the studio cut, by the Dregs for comparison, to my initial post. (I should have done so to start with - DOH).

Thanks for giving it a listen, and for the kind words. I have edited my original post, so that it includes a link to the real song, in case you want to compare. Bob Bone

Night Meets Light - a Dixie Dregs Cover - recorded by Robert Bone and Mike Reidy This is a remake/cover of the Dixie Dregs song, Night Meets Light, that I finished in 2018, and posted in the old forums, and just plain forgot about sharing it with all the folks here in the new world of CbB. Both my friend, Mike, and I, would love to get some feedback on the production aspects of the song - which we mostly were fairly faithful to the general sound of the original song, though I did "modern it up" a bit here and there. Feedback from you folks would mean a lot to both of us, because while we chose this song because of a profound love and appreciation for the beautiful playing in it, we also wanted to use the process of engineering an existing song, as a way to gauge where we stood in terms of crafting a finished product, and by replicating the original song, we could compare our version with the original, we could figure out how well we were "getting it". There is a considerable pool of diverse talent from the Cakewalk community, as musicians and as engineers, and I consider folks here to be my giant disfunctional musical family, and there truly are some experts inmusic production here - certainly way better than me (I am pretty much a keyboard player who tries to additionally wade through the music production process). So, be gentle - and also, please be honest, because I will be taking any feedback to heart, to help me get better at all of this. As far as the playing of the parts, we tried to nail those as best we could, to put our best into honoring the Dixie Dregs, and in particular, Steve Morse, who authored the original song way back in 1978 (their What If album). My friend, Mike Reidy, plays the guitar parts, and the remaining instruments were played/sequenced up by me on my keyboards (violin, keys, bass, and drums). Transcribing the drums took me almost 3 weeks, because they are different pretty much all through the song. Then, near the end, the drums get pretty active, and that was a challenge to faithfully decipher. Oh - lastly, the video was just made to give folks watching in YouTube something to look at while listening to the song, and is simply a series of pics of the Dixie Dregs, pulled from the web. It is the music itself that I hope to get feedback on. THANKS to anyone who read all of the above, and even MORE thanks to anyone who invests around 8 minutes into helping me and my friend, Mike, get better at music production. I hope you guys like it - I edited this post, to now include a link to the real Dregs studio cut of the song, down below mine, for comparison. Link to real studio cut by Dregs:

OK - so I guess Nomad Factory had some sort of bundling deal for presumably a prior version of Sonar, and I have a friend who has used BlueVerb DRV-2080 in some projects, and has had some recent crashes in at least one project that does use BlueVerb DRV-2080, which seems to be a Cakewalk Edition version, from 2013. There was maintenance applied by Nomad Factory, as general maintenance, to all older products, from 2015, and I want to have my friend switch to using the more currently maintained version of the plugin. The issue is that the newer version, after install, only runs in Demo Mode now, and I see no evidence of having any product key or serial number or whatever, from the older version that had shipped with a prior version of Sonar, so I do not know how to get the more currently maintained NEWER version I just installed for my friend, to become licensed again. Does anybody know what sort of license code would have been associated with the original version of BlueVerb DRV-2080, that shipped with some prior version of Sonar? (I am hoping to be able to plug in whatever licensing code was associated with the old version of the plugin, to authorize the better-maintained 2015 version of it). Thanks, Bob Bone

I always record seperate instruments on separate midi tracks. If you DO really want to combine them into a single midi track, the link above, on the different recording modes, should guide you on how to do it - I just again would never do it that way. Bob Bone