What's wrong with Sound Libraries?

I’ve come back to this many times over the years & never really got an answer. Anyone here the wiser?
Simple scenario is this:

Already have TBs of sound libraries installed on a dedicated volume (thunderbolt 3 RAID 4) & this includes for various manufacturers including Native Instruments, ToonTrack, MOTU, Abelton, Spectrasonics and Steinberg.

So, when setting up a fresh OS install - either on a clean install, same disk , or on a dual boot system, or on a new computer - there is then the need (of course) to re-install various VIs. There should NOT however be the need to re-install and/or long-wind download GBs of sound libraries yet again. They already exist and are located on the Sound Libraries volume.

In the case of most other manufacturer’s VIs, it is relatively simple to install just the VI, then launch, then set the path to where the libs are.

Except it would seem for Steinberg Absolute 4 or HALion, Groove Agent, Grand 3 etc. These demand downloading the entire libraries every time, otherwise the Sound Library Manager can never register and locate the Libs. There seems to be no way to simply locate the existing libraries without re-installing over the top of them like this, and, Steinberg seems to be the only one who continues to persist with this time-wasting sloppiness (in 2020).

Am I missing something obvious? I can’t say that any amount of trawling seems able to pull up a solution, also is not presently possible to raise a ticket because am unable to login into MySteinberg (yet again).

Thanks in advance for any insights.

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.


I do see that you use Mac OS, and not Windows, but the same principal should apply.
It’s not necessary to reinstall the sound libraries every time you remove or change anything HALion.
Managing libraries off on different devices/partitions doesn’t have to be difficult either, if you take advantage of OS file system junctions or symbolic links.

Figure out where HALion installations, or any Steinberg Host that comes with HALion SE content usually puts things by default for the Mac OS under the conditions that you like to install it (Single User Only, or Available for all Users/Accounts).

Mac OS supports file system junctions and symbolic links as well. Just be sure that if you copy directories off to other partitions that you do it in a way that PRESERVES all of the relevant file permissions or your file system links might not work properly. If you want to move things to new devices, please COPY them, rename the old directory, make your links, and TEST THEM to make sure they work (rather than ‘moving’ them). Once you confirm it works properly, you can go back and delete directories holding the original copies from your system drive.

Simple backup notes:

Before doing a destructive (one that wipes the file-system and/or reformats the system partition) re-installation of an OS.

Back up all your user account directories. On Macs, this should usually have you covered for just about anything you’ve made while working with the OS as a regular user. (If you didn’t have to sudo in to do it, chances are it’s somewhere in your user profile directory structure).

Backup %SYSTEMDRIVE%/ProgramData/Steinberg (or the equivalent for the Mac OS, I’m not sure where it is).

If you have ‘registered’ any libraries living elsewhere on the same partition using the Stienberg Libray manager to any directories outside your %USERPROFILE% directory structure, then back those up as well. Restore them to the same place after your new OS installation is in place.

If you do that…re-installation of HALion should be a breeze. You do NOT have to reinstall all the sound content if you restore those directories to your new OS installation.


I almost forgot…

At least this works for windows…

Say you have some folder with a bunch of HALion vstsound archives off on some obscure drive or partition. Maybe you KNOW they are not registered, or maybe you aren’t sure?

After having installed HALion and the accompanying Steinberg Library Manager, Double click a vstsound file and the Library Manager should launch. It’ll scan all the vstsound archives living in that same folder and give you information about them. If they’re not already registered as being installed, you can do so from there, with options to run them from where they live (a symbolic link is placed in one of the directories discussed previously in the thread), or to ‘move and register’ the library to a new location, or to ‘copy and register’ the library to an alternate location.