Steinberg Library Manager Move failed, and in the end, did nothing at all

Dorico
1

After recently installing all the Dorico-related VSTs to internal drive on a brand new M3 laptop, and having the VSTs take up too much room, I finally got a big external SSD and so, I am attempting to move my VSTs to the external SSD. First, I reformated the new Thunderbolt 3 external SSD to APFS Case Sensitive.

I am receiving dozens of errors from Library Manager for various VSTs, of the form:

Move ‘/Library/Application Support/Steinberg/Content/VST Sound/ADD_SMT_666_Iconica_Ensembles_Presets.vstsound’ to ‘(my volume)/VST_2025’ failed!

And also, the “Remaining Time:” indicated by Library Manager keeps increasing constantly and has reached ridiculous levels, after running for ten minutes now, it is indicating it will take 79h to complete. It seemed to successfully move “HALion Sonic Factory Content” (seems to have been moved first, even though it is not alphabetically first in the app’s window) and Iconica Sections & Players according to the app’s green bar, but there are no files in the SSD’s directory.

Library Manager ‘prohibits’ quitting the app until completion, so, I guess I will have to wait overnight at least, to see what happens. I don’t see why such a move should take much time, given Thunderbolt 3 speeds. …Update… After 20 minutes, even though “Remaining Time:” was indicating over 100h, it ‘finished’ (but actually, moved nothing, as noted above).

:-/

Anyway, the question is, how to I “uninstall” all the VSTi from my internal drive, and instead install them on the external SSD. I do not want VSTi taking up my internal space (which is why I avoided installing any VSTi in the first place). I don’t want them in “/Library/Application Support/Steinberg”.

Additional note… the app did not ask for permission to access the external drive, and macOs Settings show it has access to Downloads and no others listed (can’t add these directories manually in Settings, it seems). If it is permissions-related and it didn’t have permission to Move then I don’t know why it wouldn’t have generated a macOs prompt to access the destination.

2

It certainly sounds like a permissions problem, i.e. that for whatever reason Steinberg Library Manager cannot write to the chosen location. I don’t personally know enough about the intricacies of permissions in macOS to know why that would be. You could try temporarily allowing full disk access for Steinberg Library Manager before making another attempt at moving the content.

3

Hi @superblonde , you need to go to the system preferences and in there give the Steinberg Library Manager full disk access.
Similarly as shown here

2 Likes
4

Ok. That link didn’t work, but I know what you mean. So I granted Full Disk Permissions to the Steinberg apps. I can’t test this fix currently though since I already worked around it in a manual way: I manually moved all .vstsound files (under Application Support in a couple different Halion directories) to the external drive and then double-clicked one of the files in each of the directory to register them recursively in that new location.

The macOs Finder Copy of the 200+ GB’s of VST files only took about two minutes… whereas, Library Manager had previously taken 20+ minutes to try (and fail) to operate on the same files. Whatever Library Manager is doing during it’s Move operation, it is dreadfully, needlessly slow.

Another awkward situation is that the Download Assistant apparently installed “Content HALion 7” directly in my /Users/me/Downloads/Steinberg/OSX directory. Perhaps because HALion 7 was installed after full Iconica, which does something strange to the Download & Install directory preference since Iconica is so big? These numerous “Content HALion 7” .vstsound files don’t show in any Library Manager collection. So I have deleted all of Downloads/Steinberg manually, where nothing should permanently reside anyway.

Maybe (assuming Full Disk Access is not the preferred method of solving this problem, which it probably isn’t) the Library Manager needs to attempt to open the target Move directory before starting it’s Move operation, or something like that, so that macOs will pop up the Grant Permission window, first.

Manually moving many VSTs to external worked except for these which, when registering, and choosing “In Place”, always copy themselves back to internal drive under /Library. What’s going on here - Why would “Tonewheel Organ” and these others be so special as to always copy themselves back into /Library/Application Support/Steinberg? (Now it ends up I have two copies of these files with the same large size, not an Alias, one copy on Internal and one copy on the External SSD.)

Screenshot 2024-07-23 at 7.12.06 AM
Screenshot 2024-07-23 at 7.12.06 AM752×818 61.5 KB

Screenshot 2024-07-23 at 7.14.45 AM
Screenshot 2024-07-23 at 7.14.45 AM2200×1416 532 KB

5

Hi @superblonde , you are quite right that the whole installation of vstsound files is quite messed up on your computer. I’m not the author of the installer or the Steinberg Library Manager, but this is how it is supposed to be:
The sound installer also invokes the Steinberg Library Manager who puts the files into place and registers them with the Media Bay, so that they can be found inside Dorico resp. the plug-ins in the VSTAudioEngine.
So the Library Manager puts everything in the default folders underneath /Library/Application Support/Steinberg/Contents.
If you want to move the vstsounds somewhere else, but best do that via the Library Manager’s Move function (the Move buttons on the right of the screen). In you do that LIbrary Manager moves the vstsound file to the new location (whereever that might be) and it the original location it will put a symbolic link to the file in the new place. By that nothing needs to get (re)registered, the Media Bay will find everything by accessing the old.
But in order to move files all over the place, it needs full access to any disk.

Now you know what is supposed to look like.
If I were you , I would completely remove the sound files and reinstall them again, but before doing so, delete the doubled stuff in both locations.

6

There does seem to be something unique about these particular vstsound files; the files are not listed in Library Manager under any library or any category, can’t reside on External, etc:

The question in that thread is similar to what I also see and is unanswered:

“Is there any way to move these files? They are on my space-limited boot drive and since they’re not in the Library Manager I can’t move them to a secondary drive using that utility…?”

It seems, for mysterious reasons, some of the VSTs (which may not even be sounds) are only allowed to be on the Internal, so, registering them ‘magically’ copies back to Internal if they were on External. Some of these VSTs may be from Cubase installation (and perhaps not the “Content” installation, but the app installation); but, it is impossible to know which file corresponds to which app, or even which library (VST bundle) since this information is not published in any user documentation; and difficult to know which app installed which content, since Dorico is not a Library Manager “category” (not that it should be, which might be more confusing).

Similarly, from Tonewheel Organ and Halion 7 - #8 by Dave :

The issue I have is that is is that I can’t see a way to cross check the sound file with the preset names.

The Library doesn’t show the sound file name FCP_SMT_047_HS_Tonewheel_Organ_01 and the Halion sonic 7 and Halion 7 only show preset names. … I would have thought that there would be a list which shows which program names are associated with which vstsound file. It all feels a little messy as it stands.

I agree with that. A bit messy as it stands.

7

To bring a little light into the dark, although I’m not the expert on this topic, but here’s a bit of explanation. Vstsound files can hold all sorts of information. First and most important it holds the sampled sounds. This is the raw data so to speak. If you sample a real instrument, you record the instrument at various pitches, dynamics or playing techniques. So you end up with a collection or container of little snippets. In order to play the right snippet at the right time there are preset files. A preset tells HALion which of the snippets to load into memory and to play under what condition (playing technique or dynamic or layer). So a preset may even reference snippets from several containers. To give an example, if you look through the piano sounds in HALion Sonic, you’ll find layered sounds of piano plus strings. In this case the preset will reference sound snippets from 2 different vstsound files. For the user this is all transparent.
And that FCP_SMT_047_HS_Tonewheel_Organ_01 is just the container for raw samples of an electric organ and it does not know by which presets it is referenced. And to be honest, I don’t know how to actually find out.
I also can’t explain why that file always ends up on your internal drive again. You could try moving that tonewheel container by hand (by drag and drop in the file browser or via a command shell) and create a symbolic link back to its original location. If you don’t know how to do that, we could have a remote screen sharing session.

8

I’m no expert here, but I believe that the Tonewheel organ vstsound file is one of a handful that are considered “essential” by HALion Sonic and so are part of the HALion Sonic application installer rather than the content installer. (This is also true of some of the reverb samples.) That may be why it can’t be moved around like the others.

9

That could well be, Richard.

10

Is it possible that the application requiring ‘full disk access’ changed recently? As of Dorico 5.1.70.2200 on macOS Sequoia 15.1.1 I find that I too now see the “Move … failed!” message unless I grant full disk access to the ‘Steinberg Download Assistant’.

11

Not so far as I know, no. And in any case, it would be Steinberg Library Manager that requires Full Disk Access rather than Steinberg Download Assistant.