Speaking as a moderator, this kind of condescension is not appreciated. The sequencer is used successfully by a diverse demographic, and there’s no requirement that they learn advanced file system commands.
5 Likes
I have had applications not play nice with Junction, and even Symbolic Links on macOS.
This is a big reason why I replaced my MPC with a Maschine. It installs all expansion content to the system drive, and it will not work if you use a Junction to move it to another drive 50GB+ of content forced onto C: is not fun - esp. on machines without user accessible storage.
I’ve tried using Arutia Software Center to relocate the Resource directory to an external SSD (it creates a SymLink pointing to it - its literally a feature of the software) and it broke all of V and FX Collection + pigments until I deleted the SymLink and moved the 30GB resource directory back to the system drive.
Since the applications themselves have to access the ugins through that link, you need to make sure you test compatibility when doing this, to avoid hickups at bad times.
Personally, I vote to leave them in the default location.
My Bad. I sometimes get a bit testy when I see trite arguments being advanced in defense of one’s position.
The gist of my arguments is quite simple - there is a simple and easy solution available to the problem being described.
It is not even a particularly “advanced” solution. Learning how to use and make links is trivial compared to learning Cubase itself, or even reading a piece of sheet music.
Having the ability to set additional directories for VST3’s would be an additional user convenience option, but lack of it does not come anywhere close to rising to the level of a “defect.”
I am quite sure the overriding concern of the VST3 developers, in choosing to standardize on a common directory, was to avoid most support problems caused by installation directory proliferation. A noble goal that satisfies the vast majority of Cubase users while avoiding the obvious pitfalls.
The few users that do take issues with installation directories and a drive getting full are generally quite advanced in their understanding of the file system issues involved and easily capable of using the file system effectively.
There will be outliers who have a full hard drive and have no idea to how to manage it. This type of problem is not something unique to Cubase users, and anyone who has ever spent a day in technical support knows exactly what I am getting at. Giving these types of users the ability to set multiple directories is simply asking for trouble. You may solve their problems in the short term, but they’ll be back guaranteed.
Symbolic links / junction point: JUST SAY NO (and not because I don’t know what it is / how to do it).
The last thing we need going forward is for people to be applying such VERY antiquated work-arounds to problems that no longer exist (the reasons these methods were created in the first place … DECADES AGO).
Note: a work-around like this isn’t a fix or a solution, it’s a work-around. As such, they’re higher maintenance and potential points-of-failure. On top of all that, it’s not user friendly at all to the majority of users. Did I mention antiquated?
As stated, VST3s are executables with a small footprint. There is no storage issue here, and if you have a reasonable amount of memory, there will be no disc-perf hits her either (they will load into memory and work without clashing with your OS).
And also (as stated), store the data (samples) elsewhere. Most apps allow this and if they don’t, complain loudly to the developer. Also note that while some apps do not provide a user friendly way to specify alternate install paths at set up, they do allow you to move it later (move it, run the plug-in, and it will ask you to “locate” the new location).
Please, let us not continue to use the wood-and-metal wheels (duct-taped together) of operating systems from the previous millennia.
Chris
1 Like
Indeed. Though I wouldn’t say Symbolic links are strictly outdated. They do work, but there’s the problem of stuff that can go wrong as a result of using them over time. For a person who’s up for learning the ins and outs of it, and can tolerate it when things break (and can then fix) it’s great. But it’s not for everyone.
Symbolic links are not outdated or antiquated at all.
They have never been very useful in Windows systems, but MacOS is using them a lot (it is based on BSD Unix) and all the Linux and Unix derivates have tons of symbolic links in them.
1 Like
The enforcement of one particular location for VST3 plugins is as well a conformance to Microsoft guidelines for shared executable components as well as a “lesson learned” looking back at how cluttered the handling of storage paths with vendors for VST2 plugins has been.
With very few exceptions it’s not the plugin executable components, but rather accompaniing data files and especially samples. I do expect indeed the plugin devs to provide means for installing sample content or even additional data of relevant size to a user selectable location. A number of them does it this way. In addition I would really appreciate for more developers to install the plugins into a subfolder of the VST3 path instead of putting all of them into the root. Or at least choose the sub-folder to accomplish that. Some let you select the folder by itself.
To manage all that stuff I do use symlinks/junctions for subdirectories and particular files if required. And it does work. And virtally all VST3 plugins get their place in a reasonable subfolder, if it is not installed their by default or selectable means.
Cheers
Mike
1 Like
Out of curiosity, why are you doing that? I couldn’t care less how the plugins are organized in the VST3 folder. I mean, it’s not like in Cubase 6 days with the old plugin menu that reflected the folder structure on the hard drive. With the plugin manager, it has become totally irrelevant imho. Sure, for looking at the folder in windows explorer, it is a bit nicer if they are in sub folders with say the company name, but it is not necessary anymore.
No, this is no solution. This is an unnecessary hassle from the owner. It should be an easy choice during both - the installation and in settings later on if needed!
Nobody cares how the programs and VSTs are structured on C:.
I handle it in such a way that all programs are installed where they want to go. This causes the least problems with updates and admin rights. And basically NO data NO projects NO audio on C:. A hard disk image is then repeatedly (6 weeks) made of the stable system. If something happens then, you can import the hard disk C:\ again without affecting the data. The system will be cloned back in 30 minutes. (I use O&O DiscImage)
1 Like
Unfortunately, using a directory junction like this is not a solution for some plugin vendors: I’ve moved the VST3 folder to drive D: like you describe it, but for these two vendors/plugins, this messed up the licensing, so the plugins were not usable:
- Universal Audio (UAConnect, native)
- East West Opus
After moving the VST3 folder back to drive C:, it worked.