Cleanup time

one person's approach...
 
I create two directories "c:\program files\vstplugins" and "c:\program files (x86)\vstplugins", and under them I create separate directories for instruments and processors. I edit the registry so that it points to the two root directories, so the most I have to do is move things around a little under each. Most installers let me specify the specific directory anyway, but this covers the exceptions.
 
I keep processors and instruments separate so that my audio editors don't have to sift through a bunch of plug-ins they can't use. If you are not using a program like Sound Forge or Wavelab you can skip that step.
 
Under each sub-directory (e.g. "c:\program files\vstplugins\instruments") I further divide things by developer. This lets me spot duplicates very quickly, and helps me keep everything up to date.
 
It takes a little time to set it up, but once it is established it pretty much takes care of itself.
 
Every once in a while an installer will ignore my instructions and put things in the "official" default directory, which is
"c:\program files\steinberg\vstplugins", or in the case of Cakewalk "c:\program files\cakewalk\vstplugins" and when they aren't discovered by my programs I know to look there, and move them to my directory structure.
 
VST3 plug-ins are a different case, and seem to behave quite nicely in their default locations. That might be partly because they are always x64 architecture files?
 
It is a mess... no question.
 
The thing that drives me crazy is when a host mis-categorizes a plug-in. Cakewalk (of all programs) identified Session Drummer 3 as an x86 processor. Took forever to figure out why it wasn't showing up as a vst instrument!
 
Good luck!

as i go thru these, I am wondering if some of the newer VSTs are installed as both 32 and 64 bit?  I don't want to remove the 32 bit plug cause i'm messing around in 32 bit Acid.  ie, ADDrums2 is a newer install and it is in both the (x86) dir and the C:\Program Files\Cakewalk\Vstplugins dir.  
another discovery... you can't change the file location for a dll in the vst manager... i guess i'll have to delete the file in the dir and rescan all vsts so it finds the file in a different directory.

Do you have a separate storage device? If so, collect the  plugins you suspect you may not want, save them in folders with the same name as where they came from with some kind of marker i.e "32 bit Plugins 2" or "B" or "back up" or "removed"  or something like that. drag folder to extra device. then you know where to place them if you need them back. This way, they won't be scanned because they are not there. I've thought about doing the same, because I know I have redundancies, especially with identical 32 and 64 bit plugs, VST 2 vs. 3, etc.  

I kept ONLY a 64-bit path to plugins present in the 64-bit Sonar, and an EMPTY 32-bit-path in the 64-bit plugin path too. (Then as I tested 32-bit plugins to see if they would run OK in 64-bit Sonar, I would add them to this special 32-bit plugin folder that was built to be completely separate from the regular folder with 32-plugs for 32-bit Sonar).
 
The reason I did the above, was to go through the manual exercise of figuring out which 32-bit plugins might test out properly in 64-bit Sonar, in which case they could STAY in the unique 32-bit plugin folder added to 64-bit Sonar.  I would then take a few more 32-bit plugins I wanted to keep trying to use with either BitBridge or JBridge in 64-bit Sonar, and would toss THOSE plugins into the special 32-bit plugin folder added to m 64-bit folder paths.
 
Any plugin that caused problems simply got deleted from that unique 32-bit path that had been added to the 64-bit Sonar, and since it was never disturbed in its ACTUAL 32-bit plugin folder that my 32-bit Sonar uses, it would cheerfully and correctly continue to run just fine there.
 
And, so  the testing process would continue, and at the end of the testing, I was left with m 32-bit SONAR install having all of its 32-bit plugins happily running just fine, and my 64-bit SONAR had all of its 64-bit plugins already present and working - no problem - and it ALSO had a fully TESTED 32-bit plugin folder that ONLY contained 32-bit plugins that tested CLEANLY to run in a 64-bit Sonar.
 
I HOPE the above makes sense, as I am so tired I cannot see straight anymore.  I have been up for 23 hours and 45 minutes as I type this.
 
The last thing I did was then to go look to see if any of the 32-bit plugins had been converted and released as 64-bit versions, which would then eliminate the need for a 32-bit one to be run with either BitBridge or JBridge in 64-bit Sonar.  That further shrank the list of remaining 32-bit plugins I would potentially use in 64-bit Sonar.
 
I finally got down to just a couple, MinimogueVA and ARP2600VA, which were great freeware programs, and they did run in 64-bit Sonar, but they DID have some weird behavior sometimes.  My solution was to take advantage of a fantastic sale by a company called Arturia, for a software collection of 10 64-bit synths that included a 64-version of the Minimoog, as well as a 64-bit version of the ARP2600, and it came with another 8 or 10 synths on top of that, like Prophet 5, Juno 8, and a BUNCH of others.  That whole collection goes on sale every couple of months for like 50% off, so I got like 10 synths, all 64-bit, for something like either $150 or $199.  Once I got those installed, I had NO more need at ALL to run any 32-bit plugins in a 64-bit Sonar.
 
If you can perhaps post back with a complete list of the 32-bit plugins you still have, I would be happy to look them up to see which ones have released free upgrade versions to 64-bit.  I would be happy to help. :)
 
Bob Bone