HALion always keeps track of two directory paths for content.
One at your user account level. This path can hold information that each user on the system makes. Not sure about Macs, but for Windows this is: %USERPROFILE%/AppData/Roaming/Steinberg/Content
Others who log in might not see this stuff when they go to use HALion. I.E. If you have two accounts on your laptop. One for Sally, and one for John. Sally and John both start out with the same stuff. Sally can make presets and save them during a Cubase Project. She logs out, then John logs in. John will NOT see Sally’s presets, and she will NOT see his! John and Sally can each maintain very different HALion workflows, settings, and personal content sets. John and Sally can also use the Stienberg Library manager to register personal libraries that others using the system cannot see or use!
If you back-up user account information, and restore it after redoing your OS…in theory, things should be good to go here! The exception would be if you have broken links to files that have been moved, or no longer exist. In these cases, if HALion comes across such a link, it notifies you that the file is not there, and asks if you would like to locate it. If you pick yes, you get a file system dialog to go hunt it down and repair the link. I think you can also elect to ignore it (until next time HALion tries to use the link), or totally delete the reference to the link/sound/preset. The lesson here is…HALion keeps up with all this through actual vstsound archives and vst preset files, or through file system shortcuts or symbolic links that all live pretty much two places on your system.
One for any account on the system with permission to launch and use Cubase. Not sure about Macs, but for windows this is:
This one is maintained and scanned for ALL user accounts on the system. This directory is generally where the default slate of vstsound archives are kept when a HALion Library is installed. If a library living in a different location is ‘registered’ using the Stienberg Library manager, while set to ALL USERS mode (if there is no switch in Library Manager, then running it in administration or sodu mode vs single user mode makes the difference), then virtual shortcuts or symbolic links pointing to the actual vstsound location on the filesystem are STILL placed in this directory.
In short. HALion only knows about vstsound archives and vst presets (or symbolic links pointing elsewhere) living under the fore-mentioned two directory chains. It keeps these directories monitored for content at all times. If a file goes missing, or a link gets broken, HALion asks you if you’d like to repair it by pointing to the file, or remove the link.
At install time, you can specify if most things HALion should be limited to a single user, or available to ALL user accounts. If you chose to ‘only allow a single user’, then MOST if not ALL of the HALion content might go directly into %USERPROFILE% of the account used to install HALion. Otherwise, you’ll get a main tank for shared content, PLUS each user has the ability to maintain their own ‘personal data sets’ involving things Steinberg/HALion/Etc.
So, you shouldn’t ever have to reinstall the content libraries just to do an OS repair (that doesn’t reformat the partition), or make a change with HALion (Or Steinberg Hosts that come with HALion content) itself. Of course, it WILL be your responsibility to back up and preserve anything in your user account data files (settings, personal libraries, presets, etc.), and to back-up any directories living on the system drive with actual library files or links pointing to such files!
When you use the Stienberg Library manager…this can allow you to ‘register’ libraries that live in places other than the two paths above, but the beauty of it is…a symbolic link of some sort still goes into one of the two paths mentioned above (simply pointing the OS to another location)! As far as HALion knows, it ALL lives in one of the those two paths. Again, if HALion comes across a link that isn’t pointing to a valid vstsound archive or VST preset, it’ll notify you, and give you the option to locate it (it gets re-registered to the location then).
Personally, since I like to keep sound libraries in places other than my main SSD system drive (often on totally separate hardware devices), I deal with this by using a file system junction that points to the drive/partition/directory where I keep everything.
I’m careful to always check the box in installers that allow all users/accounts on the system to use Stienberg Stuff. This way I know most things Steinberg will end up in a universal directory at a default state, rather than being limited to only existing somewhere in my personal %USERPROFILE% directory. This ensure a base installation for any user account on the system (even if for some reason I want to go in as a sysop and block a given user from running things Steinberg).
HALion, Groove Agent, Padshop, Cubase, Dorico, HSO, etc. initially, and by default installed their factory content packs to somewhere in:
So, I copied or moved that directory to my alternate location (taking care to preserve the permissions and everything else),
and then made a windows file system junction pointing to the new location.
From a command prompt run in administrative mode:
mklink /j “C:/ProgramData/Steinberg/Content” “X:/ProgramData/Steinberg/Content”
At this point, from HALion’s perspective, everything lives on Drive C, but the OS knows it’s actually off on drive X.
For what it’s worth, unless there is some reason I don’t want other account users to have access to a library, then I also keep libraries I install using the Steinberg Library manager somewhere in that same default directory chain (I check appropriate options, or be sure to run it in administrative mode). This way, no matter what account a user logs into, they’ll all have access to these libraries.
HALion (as well as the Cubase Media Browser, if you happen to use Cubase) keeps those directories monitored for content on a regular basis. It also has options in the browser areas to force a scan of all the known directories holding libraries.
So…if for some reason I ever need to reinstall HALion, I don’t have to redo the content libraries. It will scan the “%SYSTEMDRIVE%/ProgramData/Steinberg/Content” and “%USERPROFILE%/AppData/Roaming/Steinberg/Content” paths by default unless you’ve forced it to do something else somehow when installing it.
All I have to do is check my windows file system junction link. Make sure it is there, and pointing to the right place. I can open HALion, go to a browser pane, and force it to rescan the libraries.
Furthermore…if I didn’t use a symbolic link…and kept everything on drive C…I still would NOT have to reinstall the libraries. It works like this.
By default libraries go here if HALion was installed with the ‘allow all system users to use’ box is checked:
If that box wasn’t ticked at install time, then some things might go into the user’s path instead. Also, presets I make while working with HALion, plus other things I might do while working with HALion from a non-administrative account can also end up here instead of the directory mentioned above.
While you can use the Steinberg Library Manager to keep content at different locations, windows ‘shortcuts’ (a form of file system symbolic link for windows) that point to the actual files on the system are still placed in one or both of the locations mentioned above. So…no, unless you have moved things around quite alot, you shouldn’t have to reinstall the sound libraries to update/change/add/remove HALion/Sonic/SE, or anything else that uses these HALion engine vstsound libraries/archives.
I can easily uninstall HALion, Groove Agent, Cubase, Dorico, and more, without having to remove the sound libraries.
I can install it, and it has no problem finding everything it needs in these locations:
To be up and running again.