I have a player connected to an instance of HALion Sonic 7 with playing techniques that call playback techniques which, under my expression map, send a program change and a MIDI channel change to HALion. In this video, the technique “65 12” changes the program to 65 and the channel to 12. (The notes before are on program 64.) I have HALion set to Multi Mode so that the program changes load the corresponding multi in the multi chain.
The problem is that during playback, often the “65 12” playing technique ends up switching HALion to multi 064, and sometimes it switches to multi 065 for an instant, then back to 064. I tried using 075 instead of 065 to test if something was weird with the indexing, and I tried adding multis in the chain before 064 to see if it would default to the first one, but neither of these proved true. Sometimes, it does change the selected multi to 065, so it feels a little inconsistent.
In the key editor, the playing technique bars at the bottom confirm that the only playing technique present during these notes is “65 12,” and when clicking on the notes in Write mode to audition them, the correct multi loads. The problem is just in playback.
Has anyone used a similar setup (I am writing keyboard parts with more than 16 patches, so I’m using multiple HALion multis to hold up to 16 of my “patches” each), or have any advice on how to fix this?
I wonder whether the problem could be with your expression map? Can you check that all of the playback techniques you’re using to switch between the different multis are all in the same mutual exclusion group, so that Dorico isn’t trying to combine them at each change?
I checked the expression map which the keyboard part uses, and the automatically generated mutual exclusion put all of these techniques in the same group. I made another manual mutual exclusion group with all of them, but that didn’t end up fixing anything.
Sure - I think this is a minimal example! It only has program changes, and I haven’t yet been able to reproduce the issue for program changes that aren’t the first one in the flow. But this might be a good start. I tried also making the Init playback technique change the program to something random (005) and the problem was still there.
The zip attached has the Dorico file and the three multi presets for HALion, in case those aren’t packaged in somehow.
I think your expression map was wrong? (or have I misunderstood?)
a) I think you should always have a natural switch (what to do if all else fails!).
b) Channel numbers start from 1, not 0.
This edited version works correctly to switch the sounds, but it uses MIDI Channel Switches instead of Program Changes, so the three sounds have to be in the same Multi Program in HALion. And while channel numbers are 1-16, I believe program changes are still 0-127, both in the Expression Map editor and HALion.
I think having a Natural switch is a good idea as a fallback, and will make that change in my original file!
OK. I’ve had a play around with this. (I am definitely no expert on the details of Halion)
I think you need to have Halion in multimode (Halion>options>Edit).
One problem with program changes is the time taken to load each preset (but perhaps that is just my modest PC spec)
This trivial example works for me. It loads 3 different multis via program changes and switches channels for two. Each triggered by playback techniques. ProgChange test1.zip (959.1 KB)
I’m not convinced of the utility of this approach, as the required number of switches in the expression map and playback techniques would quickly become unmanageable.
Thank you for the example! I think you are right about multi mode, and I agree that program changes are slow.
Would you be able to also send the .vstpreset files for each individual multi-program? I can load the .halpreset file you sent as a Multi Chain, but since it’s an XML file with the path to the multi-program for each program number, I’ll need to edit that .halpreset file to have the paths of those .vstpreset files once they’re on my computer.
Also, at this point, I’ve reconfigured everything so that there is only one program change at the start of each flow, and that seems to work fine, although with a slight delay to load the new program. so, it’s less urgent, but I am still confused why the first program change in each flow didn’t work in my initial example. I think it works when the program change occurs on beat 1 of bar 1, though??
so, it’s less urgent, but I am still confused why the first program change in each flow didn’t work in my initial example. I think it works when the program change occurs on beat 1 of bar 1, though??