Apr 15, 2013
Well, this is an interesting discussion to have and thought I would throw my experience into the fold.
I try to do everything in my power to keep things as organized as possible on my workstation. This does not always happen but . . . I try. This is the technique I use to keep my VST 2 DLLs (VST3 is different) organized and together.
Why would I do this??? Well, I wanted to be able to keep the VST plugins separate from the rest of the environment in case I needed to work with them in any way. It also kept the pathname short when having to enter it during installations. People ask all the time why I do this. Well . . . Say for example you want to install something that may mess with your DLLs (*cough* Automap *cough*). Well, I can take my partial or entire VST structure and manipulate it without having an impact on the rest of my setup. I could also drag the whole thing back into place if something goes wrong. I just find it easier to work with and not had any problems up to this point.
2. Folder/Files - The next thing I did was break down all of the VSTs into folders. This was either done during the installation or after. Regardless of how it was done, you should establish a folder structure for all of you VST plugins.
I have a very short folder list. There are also a few plugins in each folder. This makes things fairly easy to manage. This is not a lot of VST data to keep track of. For example the Native Instruments folder:
Please note that it is possible that if you install the VST, move it, then uninstall the VST, it will not uninstall the DLL if you have moved it. You best case scenario is to install the DLLs where you want them when you install. However, if you remember to get rid of the DLL after an uninstall, it should not become an issue.
Once you have a good understanding of how you want the VST folders and files to be structured, it will make things easier for you in the long run. You do not have to put them in the same folder that I did. Honestly, I think it could go anywhere. For example, there is nothing stopping you from creating the same structure under "C:Program FilesCommon FilesSteinbergVST2" or "C:Program FilesSteinbergVstplugins". The idea here is to remain consistent!
3. Application Refresh - Once you have decided on a folder/file structure and have your VSTs where you want them, you will want to go into your DAW software and make sure the path to those VST DLLs is listed. In my case, that is Cubase:
Generally you do not want to select the Update button. This has been known to cause crashes when "re-scanning" the plugins. I personally have never had this issue. The safest way is to restart Cubase. Updating the Plug-in Information does exactly that. It updates the information on-screen.
4. Conflict Resolution - (Not that this ever happens)
There are tools and ways to help you figure things out. A good tool that can help you at least identify the plugins you are using/loading up/scanning/finding etc. is VST-Spy from Tobybear. A lot of it can already be seen in the Plugin-Information menu.
Remember, if the install or other method did not install it into a location that the application scans, it is not going to find the VST.
Missing Plugins . . . This one is interesting . . .
VSTs have things called plugin IDs. These numbers/letters identify the VST plugin. (These can be found by using VST-Spy)
Why is this important to you? . . . . . . . Because you plugin is probably not really missing. When Cubase loads up the VSTs it looks at the IDs it will ignore VSTs with similar IDs. It will either pick the first one, alphabetical, or something long those lines.
So, if you have something called "SuperPlugin.dll" and another one called "SuperPlugin.dll" in different folders, only one is going to show up if they have the same ID. This will also apply to multiple versions (releases). There is a way around this. However, it requires a hex editor and I won't go into it here.
If there is anything else you would like me to add, please let me know.