Hello,
when I right-click a slider in my GUI and use “Assign to New Automation”, I can control it from my DAW. The problem is that this assignment is not saved with the preset in HALion, so I have to reassign it every time.
Is there a way to make this assignment permanent so that it is saved with the preset? Maybe through scripting?
Thanks!
On the surface you have two simple options.
This is just my general ‘understanding’. I might have some things wrong, but I’ll say my thing and provide my own personal workarounds (no scripting required).
The three primary doorways that content creators will give users to ‘tweak’ the sounds via remote will be:
1. Quick Controls (The 10 QCs at the top most parent level of a Program Slot are always registered in the host as QC 1 - 10, and for some hosts a parameter for the Mod Wheel might show up too),
2. Macro Screen Editors (User assigns where they like for automation with a right click),
3. A hard coded CC mod matrix of some sort. I’ve noticed some of the ‘much’ older content over the years would often have a MIDI Mod Matrix with some preset CC assignments. Sometimes they give the user the ability to change the MIDI Mod Matrix, and sometimes they had it locked, just hard set it, tell you in the manual what they are, and the user cannot ‘change’ them. Since such content typically predates the ability for 3rd party content developers to build custom Macro Editors, unless Steinberg made it and put in a way to change the MIDI mod matrix via Macro Editor, there was no way to ‘learn’ new automation methods, or change existing ones from the UI if a layer was locked/protected.
4. Possibly through parameters that are registered using a LUA Script (Macro Editors essentially work through LUA Scripts, not sure at present if there is a way to have a user LUA Script ‘register’ automation parameters with a host, but I’m pretty sure it can be done IF working with unlocked layers).
One thing that I think should work regardless, be it from full HALion, or little brother Sonic, and even if locked layers involved, is to use Multi Program style presets.
Background: HALion can save and load 3 native VSTpreset types. They all have the same *.VSTpreset file name extension. Multi Program (entire HALion Instance state), Program (The full state of a given Program/Instrument ‘slot’), and Layer (Helpful for setting aside ‘portions’ of a program tree, and it can also be treated/used as a full program preset if loaded into an empty slot, into the program table, or at the top parent level of a program).
Apparently the assignable VST ‘Automation’ parameters are kept at the global level. It’s at a higher level in the HALion hierarchy rather than being part of the ‘program’ or ‘instrument slot’ level of the plugin.
Deeper in these VSTpresets are tags and such that establish the preferred plugin for them by plugin ID, and can also tag presets as coming from the different versions of HALion and Sonic over the years. You can force full HALion to save Sonic compatible layers as well. Typically you’ll build more complex layered Sonic ‘programs’ in Sonic itself, after building the primary layers (up to four) in HALion; though, it’s possible to export a Sonic compatible preset with up to 4 layers in one go, if you follow some rules in establishing the 4 secondary parent layers.
HALion can ‘import’ a lot more things than it can save or export! Older HALion formats like FXP and FXB, industry standard sf2 (sound fonts), Roland S, some old Akai S, Kurzweil K, Giga, some older NI Konakt formats etc. In those cases HALion ports the stuff into its own VSTpreset formats, and can only be saved/exported as one of the forementioned VST3preset types.
Given this knowledge, you get one quick and easy possible solution for the issue of keeping track of user defined VST automation registrations….
Experiment with saving some full multi program presets. I think that form of preset saves the ‘entire state’ of the plugin, including automation settings, audio outputs/routing, main bus aux effects, a complete ‘program table’, etc. With such an approach you might find yourself working with more ‘instances’ of HALion than before, but it should be at least one way to ‘get the job done’. Even if working with a lot of ‘locked down’ factory or 3rd party content that you cannot somehow trick out with user LUA scripts.
I’ll run a test by right clicking some FM Lab Macro Editor controls and registering them as VST Automation Parameters. I’ve chosen FM Lab for this example because I know these presets use ‘locked layers’. Notice the little lock in the program tree here:
So, I’ll register some controls as Automation Parameters in the Macro Editor:
I registered 4 FM Lab controls from the Macro Editor to test…
For the moment my VST host is Bidule, and I can see that they are now registered in the host…
I’ll save this as a ‘Multi’ preset in HALion…
I’ll start a brand new instance of HALion and load the ‘multi’ preset….where I can confirm that the automation registrations were retained as expected, and it also shows up in my VST3 host.
Note, it might come in handy to know that Sonic offers a mode where multi-presets can be called up via remote if you need that for live performances. You’d build the multi’s in Sonic and save them first, then set up a special Map that you can find in the Options of Tab of Sonic that assigns a full Multi to a MIDI Program Change event. Sonic also gets a General MIDI mode that can do program changes by individual instrument slot. In the GM Mode, Program Changes are established in the Media Brower, and prioritized by ‘star ratings’ (Out of the box with the Sonic GM mode, you get default instrument mappings from a portion of the Sonic Selection library that’s been pre-balanced and all to play General MIDI files, and Sonic even sets up a GM2 style set of shared AUX bus effects (Reverb at CC91 and Chorus at CC93). Since HALion doesn’t take GS or XG sysex, or the extra fancy XG RPNs, you have to do your reverb and chorus settings manually, or do the right click learn thing to establish your own FX automation methods.
Quick Controls
Another approach is to use the Quick Controls. This would be more friendly if you like to work with larger Multi-Channel/Multi-Timbral HALion instances. I love this approach for a live setup, sending PC changes via remote to swap instruments as needed for each individual HALion slot ‘Each assigned to a unique MIDI channel’. With full HALion I can build very rich instruments in a single slot…all layered up, keyboard split, and even have dozens of arp/pattern/midi engines going on that do different things with the layers all at the same time! Where Sonic is far more limited in ‘layering ability’, full HALion is only limited by the power of my hardware. I think of those 10 QC parameters like having 10 Montage Super Wheels at my disposal 
For a live situation, 10 controls per channel/slot is usually PLENTY! I also know that I get the option to use predictable CC assignments as well…so on my MIDI Controller(s) I have presets all mapped out that’ll work HALion and Sonic Quick Controls every time, with anything I choose to load into HALion. With a quick glance at the HALion UI, I know exactly what they are.
Each active program slot in a HALion instance gets 8 of these assignable ‘quick control’ knobs, plus two more on the joy-stick (QC 9 and 10) that are always, and automatically registered with the host. The mod wheel also registers with some hosts as a VST parameter, while others might instead bind it exclusively to MIDI CC1 instead. Children layers also get QC banks, but the children QCs are not automatically registered with the host.
The Quick Controls at the main parent level of a program are ALWAYS registered as parameters with a host that properly conforms to VST3. They also get default CC modulation assignments for those who wish or need to automate via MIDI events. Even in Sonic, you could ‘replace’ something on one of the quick controls that you don’t need to automate with something that you do, then save your new user instrument preset.
I.E. Say you’re working with a locked FM Lab layer. Maybe there is something deep in all those macro editor pages you’d like to expose as a parameter to mod via DAW Track, and you’d like to preserve it as an ‘instrument preset’ in a way that you know the parameter will always be registered in any host as soon as it’s called up, without any need for manual assignments or registrations.
In that case, check the top set of Quick Controls for the program. Are you using all 10 of your quick controls already in a remote sense? If not, clear one out that’s loaded with mess that you don’t need to ‘automate’ and assign the target macro control to that QC knob, or the joy stick (sphere H and V goes to QC 9 and 10).
For what It’s worth, I’ve noticed that a lot of the presets in HALion don’t even use the joy stick (Sphere H and V) out of the box. Check to see if those are open and put them to use 
Example: Here’s a preset from FM Lab. I notice right away that that the Joy Stick (sphere) isn’t even being used, nor is the mod wheel.
So, I can go to any parameter back in the Macro Editors I like and assign them to one of those empty QCs that will always be registered in the host, then save a new user copy of the instrument preset. Now when using my new version of the preset, that parameter should be linked with the QC, which is always registered in a host.
Back in the SOUND tab, I can manipulate how the control should work (scale, polarity, and more).
Note, I can put more than one control on a QC if I like! I.E. One QC knob can do several different things at the same time. Hence my previous parallel to the Montage ‘super wheel’.
With a LUA User Script?
I’ll have to dig deeper to see about registering parameters to the host directly via LUA. With unlocked layers, I ‘think’ it’s quite doable. For unlocked parameters, LUA is quite powerful. I’ve only begun to ‘sporadically’ explore LUA possibilities.
When I say ‘locked down’ I mean this…
HALion provides content creators an option to password protect each layer or synth module. Such content usually has some primary parameters exposed to ‘the user’ through Quick Controls, and/or the ‘macro editor’. To get at anything else in a locked layer requires a password in LUA scripts to expose and use HALion parameters. You’d have to know exactly what those parameters are in advance and provide passwords in the code to manipulate them with a Script.
With locked layers things can be a bit more limited. Without a special password, I don’t think LUA can expose them? Without the original unlocked preset, I don’t think there is a way to snoop/parse the involved parameters or other variables involved. I could be wrong and there ‘might’ be a way to make some ‘links’ in a LUA script, but my approach so far has been to simply move around some QC assignments. 10 are usually plenty.
So, I think the ability to drop in a user LUA script to register Automation parameters from a program slot depends on the original preset. If it is content that’s locked down by the author there will be more limits as to what parameters are exposed, and which ones are not. When a content creator ‘locks’ a preset, he has to embed a special password in LUA scripts to get them to work. Even if you somehow know the password to get at HALion parameters via LUA, you’d need to ‘know’ how the parameters are named/IDed/registered to get at them. Authors always use the original unlocked version when building where they can easily see and access every single parameter in HALion. Once a preset is locked (happens by exporting a special new preset that they’ll package for distribution in lieu of the unlocked original preset), there’s no way to snoop about and discover parameter names/ids and such. You’re stuck with whatever parameters and doorways to get at them that the original author provided.
If it’s fully unlocked content then I believe you have way more options. I’ll try to look it up and run some tests, and eventually report back here if I figure out how it’s done.
If a layer is ‘locked’ then I don’t think a user LUA script can do the job (I could be wrong, and there might be ‘some exceptions’…a LUA/HALion expert will have to chime in if it’s possible).
Summary:
Experiment and practice with:
Multi-Program Presets: These should preserve the entire plugin state, where instrument program and layer presets only save information for ‘the slot’.
Quick Controls: Mastering the nature and craft of the Quick Controls: It can be a bit confusing at first, since each ‘layer’ gets a set of quick controls, and Quick Controls can also be bound to other Quick Controls within the program slot!
The QC set that always gets registered by a host by default is at the very top level of a ‘program’. As you ‘layer up’ a ‘program’ with different instrument program or layer presets, you’ll usually want to give some thought as to how they all connect and react to that top level of QC parameters (Parent most layer of a Program) that gets registered with a host via default for automation. Quick control sets in child layers don’t get registered to the host by default, but it is possible to manually register them (Not sure if and how via LUA) on an as need basis (takes us back to needing full Multi-Program presets to remember such registrations).
When working with HALion programs and layers (particularly if they are locked), get in a habit of checking out the QC assignments for each and every layer of a program. The Macro editor and the layer QC are going to be the doorway to get at any parameters the original author intends ‘users’ to have access. Sometimes those QCs in children layers are the ONLY registration exposed to the user for tweaking various bits of the sound. Sometimes you find some gems deeper down that don’t show up in the macro editor, nor on the main program QC registration. Sometimes such QCs from child layers aren’t available for remote modulation unless you snap them to one of the main quick controls first (IS remembered in saved instrument presets), or right-click and register the parameter (won’t be saved as an instrument preset, but it can be saved with an entire Multi-Program preset).
If you’re doing modulations from tracks where 10 controls aren’t enough for what you want to achieve, some layers are locked, and that can be saved fully in an ‘instrument preset’, there might be ways to bypass those ‘locked’ macro screens and make your own presets with scripts and such that can register the parameters with a host. I.E. You can bypass the FM Lab Macro presets, and work with raw FM synth modules that are not locked down in any way. Let us know what you want to build I.E. You can build content using FM Synth modules that’d work for Sonic users who don’t have FM Lab! Same concept goes for the Model C tone wheels, and the other synth modules. You’d have to build your own Macro Editors and such if you have target users that don’t own FM Lab, Model C, Flux, Auron, Trip, Trium, Voltage, and such installed….but the raw Synth and Model C modules themselves are at your disposal to build with, even targeted at users who only have the ‘free’ Sonic Player. Sample based stuff is different. I.E. If you wanted to build and share presets using that stuff, then target users must have the libraries of origin installed and properly registered.
Sometimes you can still use locked up layers (or entire presets) inside fresh new layers that you’ve made yourself and get some high level tweakability that wasn’t there before. I.E. Make your own new unlocked parent node, and move the locked content into it. It won’t always give you much, but some is better than nothing. It all just depends. I.E. one can ‘nest’ one of the locked Sonic Selection drum kits (or several copies of it) in a new user ‘child’ layer and remap things about and mod/distort/whatever in new and creative ways.
Also, as you get to know the content that shipped with HALion, you’ll discover that sometimes the ‘locked stuff’ from Sonic and SE Factory presets do have the unlocked ‘base content’ (sample layers and such) somewhere in the HAL Factory library. It’s not always obvious, but if you dig around you can often find an unlocked version (or something very close) in the “HAL Factory” library. I haven’t looked super close, but I wouldn’t be surprised for example, if there’s unlocked piano presets in HAL Factory that use the same S90ES piano samples as the locked Sonic/SE Yamaha S90ES Piano preset (I get the idea that H5 had stock pianos based on the Yamaha S90ES stage piano, which had a variety of presets for more ‘compressed’ sounds, and others for a more ‘natural/room’ staging (probably all based on the same samples with different tweaks?). Point being, if you find something cool in the Sonic content (more locked down presets) that you’d like to edit much deeper, there’s a good chance you can find presets that use unlocked versions of the same base layers in the HAL Factory library
It’s also good to know that Eagle, Raven, Skylab, Studio Strings, Hot Brass, Anima, and maybe some others (essentially everything that was ‘new’ in HALion 6) have fully unlocked layers and macros that users can explore and borrow from when making our own content. The stuff featured in HALion 6 was all about ‘content creation’, so most if not all of it is fully unlocked…the scripts, the macro pages, the whole nine yards; hence, that content is GREAT to look at to see some basics on how to make your own stuff from the ground up.
Hi thanks for your help but unfortunately in my case is not working. As you can see in the screenshots I have assigned two automation parameters of my instrument and saved the preset. When I reload the preset the automation is gone, is not saved!
You’re saving a Program or Layer preset?
Try saving a “Multi Program” preset? Multi Program presets save the entire state of a plugin instance….similar to what gets saved and embedded when you save an entire DAW project before closing it.
It’s done from here:
Are those two icons missing for you? Windows or Mac? What host are you using? Is it VST, or maybe AU in Logic, or the plugin format that AVID uses with their Pro Tools DAW (AAX I think)? If you’re using a different plugin type from VST, the way to save a Multi Program might directly come from Host instead?
I see the form area in your screen shot, but I don’t see the the two icons to Load/Save, and that’s a bit strange to me!
If missing, do you get help popups when mousing over the area they ‘should be’? If so the area should still be hot and work if you click there.
Try right clicking that top left area (Says “Init” in my screenshot above) and see what options you have. Maybe one to save a Multi Program? If not, clear the instance and see if that brings your load and save icons back? Are they also missing if you launch a Stand Alone session of HALion (Merely a test to see if the missing icons are a host problem, a problem with your installation, or maybe even a HALion bug)?
You can Load multis from that same area clicking the little folder icon, right clicking that area (That says Init in the snap shot above), or find it for reloading in the media browser with the filter set to “Multis” or “ALL”.
Once you reload it you should see its name in that blank in the top left.
If your host can launch VST3presets directly (I.E. Cubase, Nuendo, Live, etc.), again note that the preset type will be tagged as a HALion “Multi Program”.
I checked the test preset I made last night while forming my post, and it’s all there. Notice how once I’ve loaded it, the name for my “Multi Program” preset shows up in that top left area…
I saved the file as Multi, but when I reload it, the automations are gone. Since I think you have the PC version and I’m using the Mac version, this might be another bug specific to the Mac version!
Interesting…
Are those icons missing in a stand alone HALion session too?
What host are you using? It might be that full state presets for your host should be done in a native format, from somewhere in the host itself. It could be considered essential to a given host’s workflow if it maintains some kind of fancy media browser that doesn’t know about, or how to extract sorting info and such from VST3presets. Such a host might maintain its own little stash of presets in its own little world, and possibly even in containers that aren’t anything ‘VST like’ that’s powerful and easy to use.
I.E. I’m on a PC here, but some of my hosts have a way of their own to save a complete plugin snapshot in whatever format(s) it favors. It’s typically in or near the very top status bar of whatever ‘windowing’ the host sets up for Plugin displays.
Here in bidule, it also has a way of its own to make a complete instance style preset (happens to also be VST3preset in Bidule’s case). Bidule can also maintain it’s own little world of preset management (sorting, saving, loading, etc), and I can keep it all away from the big universal Steinberg Media Bay database.
Cubase Pro and Dorico also have a doorway to save a complete instance snapshot style of preset.
Or by Right Clicking Here:
Steinberg hosts all share a common database among all of their hosts and plugins when it comes to preset ‘management’ (Tagging/sorting/filtering/searching/etc), and they all favor the VST3preset format.
I haven’t used Logic since the days well before Apple owned it, and I was on an Atari Falcon, so not sure how Logic handles it these days, but there’s probably a way! It ‘might’ be that the AU protocol that Apple invented doesn’t want, or support third party plugins making Multi Programs internally and wants you do do it through the host, so the AU version of HALion doesn’t supply the option? That’s why I suggest trying it stand alone and seeing if the icons and options are missing there too. If it’s in the stand alone version, but missing in the host, that’s a sign something is up with the host (might be intentional, might be bugs in either/or the host/HALion, etc).
Only Avid thing I’ve touched is Sibelius (I still run a pretty old version), and it was on Windows. Seems like it did have a way to save AAX snapshots, and the old VST2 style of presets (FXP or something?) at the top status area of a plugin window. Finale had it too. Sibelius, Finale, and Bidule all use a playback and recording engine by Plogue.
More Pondering…..
It’s pretty evident to me that the VST3 version on Mac can at least ‘load’ Multi Program presets. Dorico uses exactly that, renamed as *.pluginstate or something like that when setting up its HALion/Sonic instances, and from what I can tell, Dorico has as many, if not more Mac users than Windows. Dorico doesn’t use VST style automation across the board yet, so there’s that. Hmm….
So I keep asking, what host are you using? Is your HALion AU, VST, or AAX? Mind trying it in stand alone, and with some different hosts?
Sorry for the misunderstanding. I meant to say that when I point my mouse where you instructed, the icon pops up. However, the problem is that even after saving a Multi, the automations are not being saved, when I reopen the Multi they are gone.
I see. What host(s) are you using, and is the session AU, VST, or AAX? Do you have more than one host to compare?
You can usually get a free and fully functional stand alone version of Bidule here if you’d like to test it out in that host:
Bidule (Click the Try It button)
It can handle both VST and AU plugins on a Mac. I believe in that host you could try both AU and VST formats (even in the same instance, at the same time) and compare. See if either, or both save and load the Multis properly.
I tested with all VST (Cubase) AU (Logic) Standalone. The automation parameters are not saved. Can anyone from Steinberg test this on a Mac? it looks like a bug because on PC is working. @Philippe_Bono
Just to tag another Steinberg employee/boss.@Gerrit_Junge
clAud9,
Sorry saving the Multi Programs isn’t working for you. Have you tried the QC approach? That should give you 10 registered parameters per slot to work with, and assignments made to QCs should ‘stick’ when you save VST presets.
Hello,
I haven’t received any feedback from Steinberg regarding whether this issue is a bug or if there is a solution available. Perhaps @misohoza might know if it’s possible to implement some code to make the automation assignments persistent?
Thank you very much!
