I use Cubase Pro 9.5 that comes with HALion Sonic SE3.
Will this get overwriiten by the HALion Sonic 3 installation?
Or will I be left with HS3 and HS3 SE as well?
My main issue is, when I first installed HALion Sonic SE back when I used Cubase 7.5 I put the contect for Cubase
on a mechanical HD.
Now a days I own two very fast SSD’s to hold my content/sample data and I’m wondering when I come to install
HALion Sonic 3 if the 25GB content will get automatically installed to the current location of the SE3 content?
Or will I get a choice where to put the HS3 content?
No, Halion Sonic SE 3 is installed separately from Halion Sonic 3. It has its own exclusive content that’s only included with the full Cubase Pro installer, but it can be loaded by HS3 and Halion 6.
All Halion content is installed into the C:\Users{USERNAME}\AppData\Roaming\Steinberg\Content\HALion\VST Sound folder.
Fortunately, I made my mechanical DATA drive my “User” location instead of my SSD (C drive) for my OS.
But now I really want to move my entire Steinberg VST Sound library to my new SSD sample drive, but I can see that’s not easy and looking at the link you kindly gave me - the tweaking to make it happen is a bit beyond my computer skills, so I will have to put up with the VST sound set being on my DATA HD - at least it’s not stuck on my SSD OS drive - which doesn’t actually have enough room left on it for a 25GB library anyway.
One sure fire (and the official method) would be to simply uninstall the content packs and reinstall them where you’d like them to go. In this case, the end installation is going to seem similar (as in files will go somewhere in: %SYSTEMDRIVE%/ProgramData/Steinberg/), but the vstsound stuff showing here will really be small short-cuts pointing to locations on other drives.
Alternatively, you can move entire directories of stuff around manually, and use file system junctions to point to them.
When I wanted to move content to a different location on my Windows PC I did it like this:
Open an administrative command prompt and copy large content folders to a different drive. In my case I simply used xcopy to preserve all the file permissions/stamps/etc and copy directories:
I ran Cubase/Halion/etc. through a few stressful sessions to make sure it was working properly. Once I was satisfied it worked, I deleted the original folder on my System Drive:
rmdir /S "C:\ProgramData\Steinberg.bak"
Had it not worked to satisfaction, I’d simply have removed the junction, restored the original directory, and deleted my ‘copy’:
del "C:\ProgramData\Steinberg"
rename "C:\ProgramData\Steinberg.bak" "C:\ProgramData\Steinberg"
rmdir /S "E:\ProgramData\Steinberg"
It has worked really well for me…I also used junctions like this to move other large VSTi libraries to alternate drives.
I later did the same for a few directories in my %USERPROFILE% area of Windows, as some of those can grow to be fairly large if you make a lot of complete VSTsound files with samples included.
Quite true for most (if not all) of the latest Steinberg offerings. That’d be the official way to do it
To run from multiple drives/partitions: I could have used the installers to uninstall, and then reinstall, etc.
I expanded the tactic to other software and libraries as well, and some of them didn’t have as flexible installers as Steinberg’s, or would simply break if they didn’t think they’re running from the System Drive.
The nice thing about Junctions…is software thinks it’s running from the device that’s hosting the Junction pointer, and the OS reflects a file path to that nature. It also makes it easy if you use removable drives and such that you might not always have connected (just fix the junction anytime your configuration changes, without having to reinstall things, or mess with registry hacks). It’s not difficult to even make little scripts on a removable devices (I.E. USB stick, or hard drive) that would run when plugged in and check/change/create junctions for you automatically.
Another example is attempting to install something that MUST be installed on the system drive, but there simply isn’t enough space for it. In this sort of case, you’d make junctions to some other partition/directory first, and then install the software. It thinks it’s going on drive C and just works
It’s kind of a last resort option for folks with small system drives. For apps that are easy to reinstall if something goes wrong, there’s really not much to lose by trying it if you’re just flat out of space on the drive.
There may well be some software out there that does not work well with this sort of file junction. I.E. I wouldn’t dare move anything from the Windows directory this way, and I’d be extra careful if I were using any kind of back-ground drive or file encryption protocols. Any application that likes to create lots of symbolic hard-links to various files or directories on the system partition file-system should not be moved/linked in this way. If it came from the “MS Windows Store”, uses the MS “Component Based Servicing” protocol, or is an app/directory updated by the windows updater system (I.E. MS Office)…keep it on the system drive (don’t point to it with Junctions)! Always test it before ‘deleting’ any original directories or files), but most things will plug right along (particularly large content libraries, temp directories, or user generated files).
With Windows, it’s pretty important to use /J (junctions) rather than symbolic ‘soft-links’ when at all possible (the exception would be if you’re trying to run things over a LAN or WAN using direct networking protocols instead of mount points). “Hard Links” can only be used if you’re pointing to something that lives on the same partition/drive. “Soft-Links” can point almost anywhere…but if an application demands it run from a specific place (I.E. Drive C), it might get confused, as the soft-link can show the true path to the file (it really depends on how the application addresses file paths in this case…coders have more than one option provided by the OS). Junctions are more like soft-links, BUT, more programs will think it’s all running from the device the junction is hosted from, regardless of the protocol the coder might have used to get/manage file path info.
If you use symbolic soft-links instead of junctions, the file path can look a bit different to some apps (showing true paths…more like a short-cut) and confuse some software. Sometimes with symbolic soft-links, poorly done installers/un-installers/updaters will just remove the top most level symbolic link itself (usually a directory pointer) and leave all the actual files in place. I.E. Instead of actually removing “E:\directory1\directory2\somefile.wav”, it might just remove the “C:\directory1” symbolic link on drive C, rather than deleting the actual somefile.wav file on drive E.
Finally, when using junctions, note that you ‘can’ point directly to individual files. I personally would avoid that, and just use pointers to entire ‘directories/folders’. My reasoning for this is long and convoluted, but as long we’re just linking directories…most of the software out there should think it’s living on the drive/partition hosting the junction, and work just fine, while the OS takes care of the rest.
If you use the junctions to milk some more life out of a small system drive:
As always…do regular clones or backups of your system drive…
Make notes when moving and linking things (MYNOTES.txt files in relative directories are good), so if you forget and need to know later, you can refer to your notes. Keep a close eye on things after running any sort of installer or update package to make sure it hasn’t broken your links and left trash behind in the target directory (take advantage of installer/uninstaller logs for apps that have them).
