Hello there,
I made a custom path for my VST2 plugins, to have them all in one folder, since every plugin dev seems to save them somewhere else.
If remove all scan paths I don’t want and close Cubase, after reopening it, they will be there again.
The marked scan paths can be deleted, but appear again after restart.
Hi,
Doesn’t Cubase crash (silently) while Quit by any chance? If you make other settings (in the Preferences, for example), is it persistent?
Do you have the lates 12.0.40 update installed, please?
Hey Martin, I thought so as well, but that is not the case. Cubase restarts without any crash report message and other settings will be saved.
Yes 12.0.40. is installed!
Hi,
It rings a bell, somehow… Could you please search the forum, if there is similar/same thread already by any chance?
I already did before opening this thread, but somehow I could not find a topic which pointed this out 
Sorry, I’m not Windows user. Do I understand you right, these are locations provided by Steinberg by default, but you want to remove them, right?
Yes exactly. Apparently you can remove them (there is this waste bin symbol and if you click on that, the paths will be deleted), they just reappear again after closing and reopening Cubase.
Also, because sometimes when updating and installing plugins, the VST2 versions get installed automatically in one of those folders, and I don’t want Cubase to scan for them there.
Different plugin versions in those folders already created some issues, so I also want to avoid that.
My setup is pretty much the same - except for the VST3 folder - I don’t understand why you have that in your list, because according to my understanding that list is specifically for VST2 plugins only.
Other than that I have also observed that I can’t take the factory default folders out of the list. The UI seems misleading in that way.
As a result, I’ve taken to a different strategy in managing how I hide VST2 plugins from Cubase: I have made different VST2 folders - e.g. VST2dupe (when there’s also a VST3 of the same plugin). or VST2inactive or VST2disabled or VST2delete (when I plan on never using the VST2 plugin again).
And for some hosts I allow them to look at the VST2dupe folder, if that’s needed for the time being.
Yep, that again is one of those UI/UX inconsistencies of Cubase. Those paths are hard coded and cannot be removed permanently, always been like that since the invention of the plugin manager. Which is fine, but then they shouldn’t be removable from that list in the first place…
Nice, I have a similar system! But still, I’d like to choose which folders are to be scanned and which not…
Absolutely. A lot of examples of that inconsistencies can be found if you look closer to all of Cubases functions.
Right now, to avoid plugins being put in those folders, I wrote a script which deletes everything from these folders on startup. Its far from ideal, but gets the job done.
“The marked paths are stored in the Plug-In Manager by default.
Therefore, they will naturally reappear after a reset.”
Got this answer by support today. So then don’t make it possible to delete them.
I think with VST3 there’s no way to configure additional folders to be scanned by Cubase. Which is too bad, because my VST3 folder is getting to be a bit large, and it would be nice if I could break it into several folders.
The reason for that is, that I also use other hosts (e.g. Unify, Bidule, Komplete Kontrol, Maschine), and I’d like to more control over what plugins are available to each host. With Cubase at least the Plugin Manager allows me to make my own collections, so that’s generally good enough for me inside Cubase. But not all hosts have that kind of “collections” ability. And of course it would be nicer at startup time to not bother scanning things that I don’t want a host to use.
I do however empathize with some of these types of Steinberg decisions, because they make things more foolproof for nubees. It’s us advanced/ambitious tinkerers, where some of these hard coded things don’t allow for the flexibility we seek. So this is not even something I’d raise as a feature request.
For a software (or hardware) provider it’s very diificult to make things ultra flexible without having lots of users shoot themselves in the foot. And when that happens, the software supplier typically gets blamed for it, regardless how unfair that might be.
VST3 are not the problem, they will be saved into C:\Program Files\Common Files\VST3 by default. Its also one of the VST3 specifications if I am not mistaken.
Also I get the foolproof thing, but in my case it is causing more issues than it helps (double installations of plugins in multiple paths causing issues when updating, etc.). Put the paths there by default, but make them editable, problem solved.
Why don’t you try deleting them from the .xml files ? Hopefully the paths will only be stored in those, but if they are hard coded into the .exe that won’t be possible.
Good idea, found a lot of other things in the XML files lately, as renaming plugins, sorting colors by name, I think I’ll give it a try.
Edit: Found a XML where the paths were written, but unfortunately it was overwritten on every start of Cubase, so I guess its hard coded.
Cubase is really keen to maintain its VST2 standard paths
- C:\Program Files\Common Files\VST2
- C:\Program Files\Common Files\Steinberg\VST2
- C:\Program Files\Steinberg\Vstplugins
- C:\Program Files\Vstplugins
Each removal of a path is completely ignored and the standard is restored the next time the application is opened. This applies both for the GUI and any manual change of the file Vst2xPlugin SearchPaths Cubase.xml. Deleting a standard path is pretended to be possible, but it’s actually pointless! It’s rather misleading the GUI still permits that…
Yep, it is not really good from a UX point of view… but then, this is an issue that will definitely be solved within the next two years or so… 
Amazing! Literally 2 years have passed since this post and I’ve just tried to remove the VST2 folders from my cubase install.
Guess what still isn’t fixed 
if it would bother me more, I might experiment with symbolic links 
