I do not want my program hard drive cluttered up with anything not essential, and forcing the storage of VST3’s there is Not Essential. Is there a reason that makes sense as to why I cannot install these to my storage drive specifically used to house plugins and libraries? I’d like to hear it.
The very idea that we cannot select where we store our assets seems like utter bollocks. Am I wrong? Happy new year.
Word.
See https://helpcenter.steinberg.de/hc/en-us/articles/115000177084-VST-plug-in-locations-on-Windows
VST3 plugins are executable program code, and as a subdirectory of C:\Program Files\Common Files is where the Microsoft Windows guidelines specify to put (executable) components that are shared between multiple applications, arguably that is where the VST3 plugins themselves should go. The way VST2 handled this was a total mess IMO and I’m glad it’s been fixed for VST3.
.vst3 files are generally quite small, most of mine are in the region of 50MB or so, and much smaller than the sound libraries that come with them, so I really don’t think leaving them on C: is going to cause any bother for most people, unless you have a C: drive that is massively too small for your needs. Given that most decent plugins allow you to store the sound libraries themselves in a different location.
Many (mainly older) applications won’t even let you install programs to a drive that isn’t C: as they can’t cope with this scenario.
In my experience, the problem is not that the VST3 plugins themselves cause a storage issue, it’s the fact that some developers don’t offer the option to store the associated data (e.g. samples) elsewhere.
Use symbolic links and junction points to move storage around while maintaining a stable directory structure.
If you do not want some VST’s occupying on your root drive, move the directory that contains them to someplace elsewhere in your storage system, and place a symbolic link to that directory in its place.
I have way more VST’s and sound content than can fit on my root drive, yet things are (mainly) installed in their default locations.
I’m curious - what’s the specific harm of storing things on your C: drive?
I’ve actually always made a point of getting a gigantic C: drive and storing everything on it (I don’t even have any other drives attached to my system). If anything, that avoids any headaches that may come with trying to store things in non-default places.
There is no harm in it at all, many people do it just that way on purpose!
My root drive is a 1Tb flash disk, and secondary storage is three hard drives of 2, 4, and 8Tb. I map storage from the hard drives onto the root drive at strategic places. Streaming from disk is not an issue here as I have about 48Gb ram.
Great if you know how; most people don’t, and frankly, shouldn’t have to.
A smaller C: (system) drive means you can backup the essential stuff more quickly (and often).
Yes, great, more convenient, but a single point of failure. Do you back it up at least daily? How often do you check that you can restore these backups?
If understanding what a symbolic link and what a junction point are is proving to be a difficulty and an inconvenience, I hazard a guess that a sophisticated program like Cubase must be a total hellscape for them, then.
A smaller C: drive means nothing at all because it is the size of the storage media you back up to that matters.
Yup, I back it up several times a day. It’s fully automated so I can just kick it off when I, say, take a break for lunch and it can churn away by itself.
The backup goes to four different locations (two local, two in the cloud that live in different geographic cloud regions for triple geo-redundancy). In addition, one of the local backups, and one of the cloud backups are versioned, meaning, I can go back in time for any of my backed-up files, which is a lifesaver if you’ve ever made a change, have that change propagate through your backups, and then a few weeks later you realize you need to go back to a version from a few weeks ago. I’ve restored backups several times for that very reason, so to your point - it’s not the backup that matters, it’s the restore 
So I try to have it both ways - the convenience of not having to worry about multiple drives, and the assurance that I can get back my data if my system blows up.
Once people get the GUI, they will fly around an application like wildfire. The vast majority of people don’t care about the OS, as long as it works for them. From reading posts on this forum, many struggle with the concept of a file system, let alone NTFS junction points.
– nice!
Personally I am quite happy with the VST3 default path, it is a big improvement over that chaos that was VST2, where with every plugin install you’d have to be careful what the installer offered as its default path and correct that if necessary, else the installer would put it someplace where it wouldn’t be found by Cubase or other applications.
Standardization is a good thing™ in my book.
And if your favourite VST3 plugin doesn’t allow you to put the sample content in a directory of your choosing, raise a bug with the developer and ask them to fix it.
See here for exactly why VST3 plugins go where they go…
“The VST3 format has a dedicated installation path all VST3 plug-ins must comply with”.
The VST3 location is a standard adopted by pretty much everybody including Microsoft.
Can’t see any reason why anyone would be concerned with this or why anyone would worry about “clogging” their C drive with this type of stuff - that’s what the C drive is for.
VP
Yes 
.
Seriously … if you are worried about how much space your VST3 plugins are taking up on your OS drive, you need to get an OS drive with a higher capacity. They just don’t take up that much space. If you are talking about sample library content, that is a completely different subject.
Really?
That seems very lazy/cheap on the part of the developer. I have never really noticed this happening with any of my VST3 plugs.
Would you care to mention any developer names? Maybe I use them, but don’t even know it.
Here are some quick instructions for implementing a junction point. I had to do this for Reason, because the software doesn’t let you change the installation directory for Rack Extensions.
I hope this works for you.
Heh, typing ‘mklink’ is way too many keystrokes for all the flying GUI wizards, apparently.
Thank you for taking the time and effort to explain this.