Hi,
Don’t know anything about Halion Sonic SE apart from the fact it came with Cubase. As I have Halion 5 can I dump Halion Sonic SE and it’s corresponding files?
Cheers
Hi,
Yes you can.
Hi,
I have Halion Sonic 2 so can I do the same?
Would it benefit my system?
Thanks and regards
Jim B
Thanks Martin, might help me save some valuable space on my 128gb SSD. Really wish i had bought a 256gb drive now 
Isn’t the Halion Sonic SE content a subset of the Halion 5/Halion Sonic 2 content?
That’s kind of what I worried about and why i asked if I could dump corresponding files. Only have 40gb left on my SSD and was looking for a way to claw back some space.
I’m really not sure but I was under the impression that any content files would only be installed once if everything is setup correctly, the Steinberg installers are usually pretty good at knowing what is already installed on your system.
I think when you install Halion 5 if you already have a version of Halion Sonic SE installed it will see those content files and only install the additional content.
Like I say I could be wrong I’m not totally sure.
No, there are umique files for HALion Sonic SE. These files contains subset of HALion files. But what is umique is the set, and the fact, Cunase can load a MIDI files and assign the sounds directly from HALion Sonic SE.
So, does anyone know which files i can delete. I know i won’t be using SE.
Cheers
Personally, I’d leave it there. The core of the Halion Engine is the same for all Halion Variants, and probably Groove Agent as well. The UIs themselves for things like Sonic, Halion 5, Groove Agent 4, etc…are relatively small plugins. The higher versions of Halion simply grant more access to more advanced Engine abilities, and whatever hooks are needed to verify licenses on your USB key, as well as more content.
Benefit of removing it:
Recovering a very small amount of disk space.
Benefits of leaving it alone:
Importing projects: If you’ve ever used SE in the past, or ever want to import content done by other Cubase users…having it there could save you unnecessary tweaking.
Less possibility of losing content/patches or breaking factory presets.
In the case of GrooveAgent SE and GrooveAgentOne, I’ve found some VSTpresets that simply will not load in the higher end variants unless you first load them into GAOne or SE and save a fresh preset. Example: GM Kit would not load for me in GA4…GA4 didn’t even see the preset. I loaded it into SE, then saved a new preset “My GM Kit” and it then showed up in GA4 and worked fine.
While this below may not be a solution supported/recommended by Stienberg, it has worked for me. I had reached a point where it was worth a try, and worst case…would be removing my junctions and reinstalling everything Steinberg if I broke it.
One of the things I did when I had a small SSD as the system drive was:
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:
xcopy /E /I /H /K /X /B "C:\ProgramData\Steinberg" "E:\ProgramData\Steinberg"
(note, the /B flag will copy any links/junctions if they exist, rather than making a full copy of their targets.)
Next I renamed the original folder:
rename "C:\ProgramData\Steinberg" "C:\ProgramData\Steinberg.bak"
Then, I set up a file-system junction:
mklink /J "C:\ProgramData\Steinberg" "E:\ProgramData\Steinberg"
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.
All vstslund files with HSSE in the file name.
Thank you guys. Will have a think about this over the weekend. Tempted to leave it after what Brian said and though your suggestion to move content from the SSD is appealing I’m sure i would mess it up somehow. I will see how much I stand to save should i delete all files with HSSE in title.
If you’re considering uninstalling/deleting these:
I’d think more than twice about it. Do you really want to get rid of your entire General MIDI patch set?
If you did, you’d lose a big chunk of what makes Halion great (in my opinion) and only get back about 1.25 gigabyte of disk space.
Halion Sonic or Halion 5 can still load and play the HSSE Basic, Artist, and Pro VSTsound sets. Example: The H5 and Sonic General MIDI Multi setups are based on the HSSE GM and Basic *.vstsound files.
If you make your own patches in Sonic or H5, there are plenty of great layers from SE content (as well as presets to simply study for an understanding of how some great patches were designed) that are very useful. While you might not be able to get at and edit the samples themselves in some of the SE/Sonic content you CAN still nest the predefined layers in a way that you are triggering their samples, and creating new user defined parameters to ‘alter’ they way they can sound. If for some reason you really need to ‘edit the samples’ from a locked SE layer, you can always use the Cubase ‘instant render’ feature to resample a layer…then do with it what you will in H5 (or whatever sample editor you choose) 
Some of the Sonic Content might also mix layers/zones/samples from the HSSE content. I.E. To get a richer variant of a string patch, it might mix layers/samples from SE, Sonic. H5 can mix and match layers and samples from all of it…
The base GM set of patches are quite good in my opinion, particularly when used in ‘context’ with each other in a ‘mix’. The fattest and richest patches offering several layers of velocity sensitivity, all wet with extra effects and stuff might sound great played solo, but they’re not always the best choice in a ‘mix’. Sometimes the simplest old bread and butter staples are still the best
Even with full H5, and quite an assortment of other VSTi and hardware synths…
I still make MUCH use of the Basic, Artist, and Pro Halion SE presets and layers (Usually through the H5 UI, but I do still have older projects lurking from days before I owned H5, so it’s nice that if I load those old projects SE is there and it just loads up and works). In fact, if a small/compact installation were essential, I’d personally feel more inclined do the opposite, and Keep SE Basic on my primary system drive, and install/uninstall the Sonic/H5 ‘as needed’ (or run it from alternate drives).
It is possible to uninstall or disable just the Halion SE UI (basically some plugins) and keep the ‘content’. The Halion Engine itself is essentially the same program under the hood for everything from SE, to Halion Symphonic Orchestra, to The Halion Grand Piano, on up to GA4 and H5, and maybe even some of the other plugins like Retrologue, Myst, and PadShop…same base engine, just custom UIs on top of it, new content, and documentation to go with it. It probably won’t hurt anything to try uninstall the UIs you don’t use, as you can always reinstall them as needed…but in my ‘opinion’ the small space recovered probably wouldn’t be worth it. Same goes for getting rid of the Sonic UI if you happen to have H5, etc.
If you kept all the ‘content’, and got rid of everything but the Big Daddy Halion 5 UI, here’s the approximate disk space you can recover (looking at my 64bit installations on Windows 10):
+050.50 megabyte: Halion SE
+132.84 megabyte: Halion Sonic Stand Alone Executable/Skins/Documentation, VST2 and VST3 plugins.
183.34 megabyte: Total space recovered by un-installing these two UIs and keeping all the SE/Sonic content.
I just kept using my system until I got to a point where I had less than 10gig of free space for the system to do its thing (not counting overprovision space that I’d set aside for the SSD to do garbage cleanup). At that point I had nothing to lose by moving things to alternative drives and pointing to the new locations with system-junctions until I’d saved up the cash to put in a bigger system drive. I ran it for over a year like that…and it did rather well.
This is great advice.
You can of course tell the installers to install the content to a separate drive at installation time.
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).
http://www.windows7home.net/how-to-create-symbolic-link-in-windows-7/
Thanks for all the advice. I think i will keep things as they are! Next stage will be to save for a larger drive then the task of installing it - which i am dreading already cos i haven’t got a clue about these things! Installing RAM is the most i have ever done inside a PC!
Amazing thread … Thank you!
Weird. Am setting up a template file and I am popping in Instruments which i use most. Funnily enough Halion Sonic SE is not in my instrument list! Only Halion Sonic 2. Can’t understand why it’s not there. Not that i intend to use it (see above). Just thought it strange that it installed with my installation of C8 but it’s not showing.
It should be under Synth in the instruments menu, if you have plugins categorized by vendor then it should be under Steinberg->Synth->Halion Sonic SE