finally getting around to cleaning up after i updated my system... had Win 32 on the C: hard drive, and put a new Win 64 OS on a new SSD, just used the old C: as D:.  Left most all docs on the now D:.   Now i have VSTs in many dirs...
C:\Program Files\Cakewalk\Vstplugins
C:\Program Files (x86)\VstPlugIns
c:\program files (x86)\cakewalk\vstplugins
D:\Plugins32Bit
D:\Plugins64Bit
D:\PluginsVST3
D:\Program Files\Vstplugins
D:\Program Files\Cakewalk\Vstplugins
 
I went thru the locations and marked the files that are still active in X3, so now I have MANY plugins in the old (pre Win 64 install) folder, and I want to deal with them.  
How would you go about this?  I'm thinking of just deleting a batch at a time so they go to the recycle bin and i can recover them if needed.  I have other progs (Reaper, etc) that refer to the plugins, but if i delete a duplicate then the progs should still find the good files so long as the folder is tagged for retrieval??? Many are Sonar duplicate plug installs and I don't want to mess them up.
Maybe this is a non-issue, but just wanted thoughts on removing old cake files off the D:, cause I don't want to screw up my current installs, which should be fine in the C:

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!

wst3
 
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?
 

There are 32bit VST3 plug-ins. What makes VST3 easier is the location is in the VST3 spec.
 
Rather than relying on the recycle bin, I would create parallel directories for the "deleted" files. This way if the recycle bin gets cleared, there is still an easy recovery path. If I wanted to move all the deleted files to a single directory tree I would still maintain the path so it could be easily restored. For example, if the deleted files were to be stored on D: create a top level directory "D:\deletedVSTs" with subdirectories for each drive
"D:\deletedVSTs\C"
"D:\deletedVSTs\D"
and maintain the paths from there so there would be
"D:\deletedVSTs\C\Program Files\Cakewalk\Vstplugins"
"D:\deletedVSTs\C\Program Files (x86)\VstPlugIns"
"D:\deletedVSTs\c\program files (x86)\cakewalk\vstplugins"
"D:\deletedVSTs\D\Plugins32Bit"
"D:\deletedVSTs\D\Plugins64Bit"
"D:\deletedVSTs\D\PluginsVST3"
"D:\deletedVSTs\D\Program Files\Vstplugins"
"D:\deletedVSTs\D\Program Files\Cakewalk\Vstplugins"
and so on
Ultimately when I was confident the files could be deleted, I would burn them to DVD and delete from the HD.
 

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.

It is a possibility. To keep plug-in lists as small as possible for each host, it may be necessary  to have a couple of 32bit plug-in directories.

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.  

Here's another approach:
I use c:\vst plugins\32 bit and c:\vst plugins\64 bit
Copy all your folders into these (so you can have the 32 bit copies and 64 bit copies if you want)
Put the ones you don't think you'll need in
c:\vst plugins\not used - so you can copy them out if you change your mind.
 
Then you just set SONAR to scan the 2 folders (32 bit and 64 bit).
 
VST3 gets installed into it's own directory and you can't control it anyway - it is something like
C:\Program Files\shared\something..... (and C:\Program Files (x86) for the 32 bit ones)
 
 

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
 
 
 

thanks Bob, but to keep things less confusing, I'm just going to have one dir for 32 bit and one for 64 bit, and if a 32 bit vst has an issue, then i may just delete it.  The only confusing thing is a plug that is both 32 and 64 bit, so my X3 64 will see the plug in both 32 and 64 bit dirs... but you have an interesting way of managing that, so I may do that.  Also, the plugs that have only a single dll are easy to manage... it's the ones that want to be installed in a certain place or have dependent files other than a single dll are a pain.
I do need to go thru and see if any have updated to 64 bit, but I've been trying to keep up on KVR cause they are pretty good at announcing changes to plugs.