I don’t use Pro Tools - so can I just delete the whole folder? or should I uninstall it using the official plugin installer?
When I install a vst3 plugin, should I install it:
Here - C:\Program Files\Common Files\VST3
or here - C:\Program Files\Steinberg\VstPlugins
C:\Users\User-name\Documents:
So now that I know that this is the location of the Application Data folders, it means I have nothing I can do about all these folders, right?
As I understand, later on these folders will be automatically filled with files? so I’m not supposed to delete any files every once in a while?
In addition to the Application Data folders in “Documents”, I also found samples folders (instrument libraries) there, and I also found samples folders in C:\Program Data - so is there a recommended path for all these sample libraries?
I don’t remember choosing these folders by myself, but it somehow got there.
Windows Developer Culture and their attitude towards users. As I’ve stated, even though the same developers will adhere to recommendations on macOS, they often will not on Windows. They don’t care enough to do so.
Bitness really has nothing to do with file locations, as the locations mirror each other regardless of bitness.
For 32-Bit VST2, I usually install to C:\Program Files (x86)\Steinberg\VstPlugins, and the 32-Bit VST3 Standard directory is C:\Program Files (x86)\Common Files\VST3.
This is the same as 64-Bit, except “Program Files (x86)” instead of “Program Files.” While the VST2 Directory isn’t standardized, the VST3 directory is, and this is where all 32-Bit VST3 plug-ins are installed de facto.
Barring a few weird scenarios, 32 and 64-Bit ports of the same application generally share the same configuration and application data files (not to be confused with things like DLL and such). This is why installing the 32-Bit port of a DAW that still ships one (like Samplitude Pro X7) only barely adds additional storage requirements to the installation.
Dropping 32-Bit won’t magically stop developers from polluting User Folders with Configuration or Application Files, Application Logging Directories, etc.
I actually don’t think VST2 installations are a bit deal, because we’re at the tail end of VST2’s lifecycle. What I would do is freeze a computer at Cubase Pro 11 (all Cubase Pro 12 upgraders have 11 on a dongle, or should ) and keep that as a backup in case I need to access any projects using VST2 plug-ins that haven’t upgraded to VST3 or don’t automatically migrate to VST3.
But on new machines, I wouldn’t install a VST2 unless there was no VST3 available - and even then, I’d consider dropping that plug-in and looking for an alternative VST3 that performs the same function (hopefully about as well as the other).
It’s actually an apt comparison, because nothing about VST Plug-in locations is inherently fundamental to either of these OSes. Nothing about macOS mandates VST plug-ins be installed in the “standard location.” Developers on macOS have simply accepted that as the standard and used it religiously, unlike on Windows.
You can move VST plugins to any folder on macOS and if the scanner for your DAW is pointed to that folder, it will scan and use them.
It really is no different than Windows, as far as that is concerned.
So, the comparison is apt for displaying just how irrelevant platform choice is in the matter. It’s all about the choices the developers make when they deliver their user experience to the end user.
Yes, you can delete the Avid Audio Folder.
Do not delete the root Avid folder if you have other components like Avid EuControl installed, as it also installs the Avid Directory. Only delete the root AVID folder if the Audio Folder is the only subfolder that exists within it.
If you use Avid Media Composer, do not delete AAX plug-ins. Like Pro Tools, Media Composer only supports AAX.
%ProgramData% is where private program data goes. It’s hidden by default. Yes, Steinberg’s sample libraries go there by default. You should manage these with Steinberg’s Library Manager application, not in Windows File Explorer.
Those other folders in the User Documents directory - most of them really should be in C:\Users<UserName>\AppData, but there is not much we can do about that if the developer has hard coded their application to create and manage application data in the user documents folder.
It’s bad development practice carried over from Windows 9x days.
I would leave much of them alone. I don’t recommend messing with it unless you know what you’re doing.
Steinberg does a bit of this on macOS, as well! I actually think they may be the only vendor doing this, across all software I have installed on my Mac.
@Trensharo I have to say, this is all very interesting to read and learn!
I don’t have only Steinberg’s sample libraries in “Program Data”, I also have other developers’ sample libraries in there (like XLN), that’s why it’s confusing.
So now I know where to install vst3 files (Common Files\VST3 ) , and I know not to mess with all the folders in “Documents”, but I’m still not sure where I should install sample libraries - in “Documents” or anywhere I want?
I don’t recall XLN (or Steinberg) asking me, but maybe I forgot.
If I want to change the location, can I just move the files to a different location, or should I contact every vendor and ask them of how to do it? (I held off my next installations, so hopefully it will be easy).
Yes, me too, I only have SSDs.
You just create a samples folder and direct every installation there?
With Cubase there is a library manager so once installed you can move to where you want with the library manager. I never got the option when installing though. With other plugins it depends on the vendor. For instance I have SD3 which does give you the option. It also allows you to move the whole library and then change the oath in the software. Others like ujam made me install all over again even though I had the audio on my m.2 drive. Rather annoying.
You could also just check the vendor’s documentation. Took me a couple of seconds and two clicks to find this on xlnaudio’s website how to move/install the sample data elsewhere:
And the XNLAudio installer has a big button “Customize installation”.
What I am saying is: a lot of especially the “bigger” products already do offer the option to install/move sample data, and most often ist is already documented.
Except for sample libraries, I install pretty much everything to their default locations, but I make sure Cubase ‘sees’ those locations. Native Instruments plugs, for example, get into a real mess very quickly if you start fiddling with their install locations.
All my sample libraries are on non system drives, SSDs or M.2 NVMe SSDs and my setup flies!
@Trensharo
So after all of this… I want to backup all my vst3 plugins + sample libraries:
so how do I know what files/folders I need to backup in order for them to work in the future?
Some sample libraries are easy to understand - they have one main folder and that’s it, but as we discussed - not all plugins and sample libraries are like that, so how do I know which folders to back up?
Honestly just make a time machine backup of your system and you’re fine. Windows has a similar backup solution that you can set up. I forget what it’s called.
Backing up just the folder isn’t really viable, anyways, since most plug-ins need to be installed and registered, or use some type of copy protection. Lots of plug-ins also have data files, etc. that reside outside of the system VST directories, as well.
Honestly, you are better off archiving the plug-in installers than the plug-in directories on the computer.
Do make an image/backup of your system immediately after you set everything up, though, so you have a clearn baseline that you can always restore to
That depends on the plugins. With SD3 the sounds are separate and the whole folder can be backed up or moved. When I have reinstalled sd3 I need only install the plugin and then locate the libraries. Many are like this.
You need to know your vsti and where they store their sounds. Some may be like sd3 and others not. Surely the manual with them all lets you know how to do this. Even Cubase comes with a library program for doing this
) and keep that as a backup in case I need to access any projects using VST2 plug-ins that haven’t upgraded to VST3 or don’t automatically migrate to VST3.
