How have you structured your VST folders? (32bit vs 64bit)

Hi,

I'm in the process of transferring my DAW to a new rig. This will also be the first time I use Sonar in x64 mode.

So far, installation has gone fine. The only question mark I have related to 32b vs 64b VST plugins.

For 10 years, I've been accustomed to having them located under c:\Program Files\Cakewalk\VSTplugins.

This folder under a x64 operating system is now known as c:\Program Files (x86)\Cakewalk\VSTplugins.

That's fine. I get that. And the VSTs I'm installing seem to recognize that folder just fine during installation. However, those that can do x64 and prompt me for a location for the x64 location do not default where I thought they would... ie, c:\Program Files\Cakewalk\VSTplugins -- instead, they propose to install the x64 VST plugin in the company's own file space... ie, c:\Program Files\Native Instruments\Kontakt\etc.

The first plugin to do this was the Superior Drummer 2.0 VST, and that one specifically requires that the x64 VST be located at a specific location that cannot be changed and doesn't play well with others. So I thought this would be a lone exception.

But now that I'm seeing this is going to be an issue going forward with 32/64 plugins, I thought I'd ask what everyone here does so I don't regret whatever I decide to go with.

Here are the options as I see them :

1. c:\Program Files (x86)\Cakewalk\VSTplugins = All 32bit VST(i)s
   c:\Program Files\Cakewalk\VSTplugins = All 64bit VST(i)s
2. c:\Program Files (x86)\Cakewalk\VSTplugins = 32bit Cakewalk-installed VST(i)s
   c:\Program Files\Cakewalk\VSTplugins = 64bit Cakewalk-installed VST(i)s
   c:\Program Files (x86)\VSTplugins = All other 32bit VST(i)s
   c:\Program Files\VSTplugins = All other 64bit VST(i)s
3. c:\Program Files (x86)\Cakewalk\VSTplugins = 32bit Cakewalk-installed VST(i)s
   c:\Program Files\Cakewalk\VSTplugins = 64bit Cakewalk-installed VST(i)s
   c:\VSTplugins\32 = All other 32bit VST(i)s
   c:\VSTplugins\64 = All other 64bit VST(i)s

Which hierarchy seems the soundest to you guys (before I commit and install 200GB worth of stuff)?

thanks.

I wasn't even aware there was competition for BitBridge. Anyone else feel the same about JBridge?

I'd also like more opinions on the VST folders set-up, if possible.

Thanks!

IMO, It makes sense to maintain the default Windows convention of installing 32Bit software under
C:\Program Files (x86)
And installing 64Bit software under
C:\Program Files
 
I use apps in addition to Sonar... which I don't want trying to access VST plugins that are specifically tied/limited to Sonar.  Thus, I use the following means to organize VST plugins
 

• Sonar's 32Bit VST plugins get installed to

            C:\Program Files (x86)\Cakewalk\VstPlugins
 

• Sonar's 64Bit VST plugins get installed to

            C:\Program Files\Cakewalk\VstPlugins
 

• Third-party 32Bit VST plugins get installed to

            C:\Program Files (x86)\VstPlugins
 

• Third-party 64Bit VST plugins get installed to

            C:\Program Files\VstPlugins
 
This keeps installs clean/organized... and offers total flexibility.
Sonar x86 scans both 32Bit plugin folders.
Sonar x64 scans both 32Bit plugin folders and both 64Bit plugin folders.  If you want to limit Sonar x64 to only using 64Bit plugins, you simply remove the paths to the 32Bit plugin folders.
Other host DAW applications scan the Third-Party (non Cakewalk) plugin folders... thus avoiding error messages from VST plugins that only function in Sonar.

Well, he just described Option #2 on my list (see OP) word for word, if I'm not mistaken. :)

Well, he just described Option #2 on my list (see OP) word for word, if I'm not mistaken. :)

 
Yep... 
Just wanted to expain the how/why

But since most Sonar plugins DO work in other applications... for instance, you can use Sonitus FX in Adobe Audition if you'd like... doesn't it make more sense to have all the audio software scan all the folders? In which case, it would make separating them in 4 different folders unnecessary. Or am I underestimating the problems that may arise from Adobe Audition scanning VST plugins meant for Sonar use?

 
As long as you keep things organized (keep 32Bit/64Bit plugin installs separate), there's no "wrong" means of structuring your VST plugin folders.
 
Using separate "3rd party" VST plugin folders allows more flexibility/control.
ie:  I use mostly 3rd party VST plugins... and I don't want my other Host DAW applications scanning thru all of Sonar's included VST plugins.  Of course, if you don't want/need that flexibility... it's totally unnecessary. 
 

In other words, should an effort be made to keep them on a separate physical drive from the OS? By the looks of things, the answer seems to be no... but I just wanted to get that confirmed.

 
Correct...
There would be no advantage to installing the VST plugins to a separate HD.
 
Now... if you're dealing with something like Kontakt, installing it's huge sample library to a dedicated "Samples" HD makes good sense (for maximum disk-streaming performance and to keep OS backups small/quick).  But the VST plugin dlls would still be on the boot HD...

CakeHead


Once VST's are located in a folder... is it possible to move them to another (say I change my mind about the hierarchy at a later date) WITHOUT re-installing them, and simply by moving those .dll's?

Most VSTs will still work if you move the the .DLL files to a different VST folder from the one that they were originally installed in. However, there are a few that will not work properly unless reinstalled. I say try it...and then just reinstall the ones that give you any problems.


-eB

I'm clearly no expert, but since x64 VSTs aren't identified as such in the dll's filename (Superior Drummer, for instance, uses the same filename for both dll's), I would be worried that installing a x64 VST in the same folder as the 32-bit version will squash the latter with the former.

Can anyone confirm this as a potential risk?

Jim Roseberry

In other words, should an effort be made to keep them on a separate physical drive from the OS? By the looks of things, the answer seems to be no... but I just wanted to get that confirmed.

 
Correct...
There would be no advantage to installing the VST plugins to a separate HD.
 
Now... if you're dealing with something like Kontakt, installing it's huge sample library to a dedicated "Samples" HD makes good sense (for maximum disk-streaming performance and to keep OS backups small/quick).  But the VST plugin dlls would still be on the boot HD...

There are exceptions to this. For example, if I recall properly, Camel Audio's Alchemy plugin (a really great plugin, BTW), installs its entire library on the same drive as the VST DLL. This is very annoying, since it's a large library. I prefer all samples to be stored on separate drives. I can't recall if you can manually move Alchemy's sample files later (I've left them in the default location for now), but that's one example, that for performance and space-savings sake, you might consider putting it on another hard drive. There are other similar plugins that are borderline in that their patch libraries also contain samples, and in some cases, a LOT of samples, and the developers have not yet added an installation-option, for example, to locate the samples on another drive.

Other than those few exceptions, I agree completely with Jim on this point that there would be no advantage to installing VST plugin DLLs on a separate hard drive. The vast majority of plugins that have sample libraries will ask you where to save those large sample files, and you should definitely be putting them on a different hard drive than your OS/boot/app drive.... but the VST DLLs themselves can stay on the OS/boot/app drive.

 
I find it annoying to have to explore/browse to a buried folder to get to shared content and ini files:
  E.G., C:\Program Files\Cakewalk\SONAR 4 Producer Edition\sample content\tutorials,....
     (Vista and 7 are even more annoying with burying folders/files)
 
I am very annoyed at ANY stuff put in the Documents folder. Only user stuff should be in the Docs folder. Demo Videos should not be copied to this location without triple confirmation.
 
In general  I try NOT to install music related programs into the Programs Files folder.
 
So, I have installed programs such as Sonar1,2,3,4 to folders in the C: folder: i.e.,  C:\Sonar2, C:\Sonar5, C:\Sonar8.5, etc.,...
 
Unfortunately, some programmers insist on creating folders in the Program Files folder, even though they are empty.  Truly annoying.
 
And I do NOT delete old versions of Sonar: I want access to the plug-ins and some of the utilities, i.e. studioware panel creation.
I have created a few other folders for audio stuff:
 NOTE:::  Create these folders before installing anything. And then POINT to this folder during the Sonar INSTALLATIONs. :::
 C:\AudioCommon   for installed small plugins, documents, and for some ORIGINAL shared content:
      sub-folders: (examples)
  \Dimenson
  \Pitchworks
  \Surfaces
  \Proteus
  \SharedDXI
  \Shared MIDI Plugins
  \Shared Plugins     (Sonar)
  \SharedVST          (Third party stuff)
(( This way each version of Sonar finds ALL of the plugs, cal,...))
Some plug-ins do not want to be in this folder: Kantos, Sony Noise Reduction. So Iput some of the files into the next folder.
  C:\AudioPrograms    for programs and big plugins with install routines:
        \MidiQuest
        \CDArchitect
        \Kantos
        \Sony Noise Reduction,...
  C:\Cakewalk Projects  folder is used for the picture cache.
  D:\Samples     for imported samples, and soundfonts,...
  E:\AudioProjects
       sub folders:
            \SonarProjects   for ALL project files and audio
                 \Audio   default Sonar DataDir set in the AUD.ini file
            \Presets   for presets I have used in projects, whether I created or found them
            \Templates
            \CDProjects  for CD files and for some exported wav files
            \CAL
            \MIDI Groove Clips
         And so on. 
All of this sorting provides for quicker access to configuration files, and for easier backup activities.
J      
--------------------------
How should we deal with Virus writers, identity thieves, and spammers?
 
My preference is life enslavement, as farm workers.
But I will settle for federal capital punishment, publically applied.
 
First offence for Spammers should be removal of the fingers to the first joint on their dominant hand, and both large toes (difficult to walk). Second offence takes the other hand's fingers. Third offence is 1 way to Somalia.
 
Branding the forehead should be standard procedure for all of them.
 

 
I use apps in addition to Sonar... which I don't want trying to access VST plugins that are specifically tied/limited to Sonar.  Thus, I use the following means to organize VST plugins
 

• Sonar's 32Bit VST plugins get installed to

            C:\Program Files (x86)\Cakewalk\VstPlugins
 

• Sonar's 64Bit VST plugins get installed to

            C:\Program Files\Cakewalk\VstPlugins
 

• Third-party 32Bit VST plugins get installed to

            C:\Program Files (x86)\VstPlugins
 

• Third-party 64Bit VST plugins get installed to

            C:\Program Files\VstPlugins
 
<snip>

BTW, Ableton Live (32bit only) only supports ONE VST folder! I had mine set up as above, but had to change it to accommodate Ableton. (Ugh!)

What works for me:
1) C:\Program Files\Cakewalk\VSTPlugins--all plugins installed by Sonar x64.
2) C:\Program Files\VSTPlugins--all other 64-bit plugins.
3) C:\Program Files(x86)\Cakewalk\VSTPlugins--all plugins installed by Sonar 32--bit.
4) C:Program Files(x86)\VSTPlugins--all other 32-bit plugins except for those that have 64-bit counterparts; these go in:
5) C:\Program Files(x86)\VSTs too. This prevents unnecessary duplication in Sonar 64-bit; so far the NI plugins I have that have 64-bit versions have worked OK so no need for the 32-bit duplicates to show.
YMMV.

*bump*

What happens when there's a x86 and x64 version of the same plugin in separate folders, but Sonar x64 scans BOTH folders... does the plugin show up twice (once wrapped in BitBridge, and once not)?

I assume there's no problem if it sees both. I've seen 32 and 64 bit versions appear after a scan in the list of VST effects. One can just highlight the 32 bit version and exclude it from being visible in the future. I think having both appear is good, should you ever need to chose the other one.

My question again, if anyone knows this: Is the Program Files (x86), that can include a Cakewalk file, and a Vst folder, there for organizational convenience? Or is putting ALL VSTs into the Program Files/Cakewalk/VST folder, vs. diving them up into that and the x86 VST folder a problem?

Other than the perhaps inconvenience of having 32 and 64 bit versions appear after scanning, which can be hidden, or the user can just pick the 64 bit. I don't believe the inclusion or scanning of 32 bit versions pre-empts allowing the 64 bit version to appear or be used. Any thoughts on this?