Proper MIDI automation of controls across multiple MIDI channels?
-
The MidiAutomationObject is this
{ "Controller": 1, "Processor": "Interface", "MacroIndex": -1, "Start": 0.0, "End": 1.0, "FullStart": 0.0, "FullEnd": 1.0, "Skew": 1.0, "Interval": 0.01, "Attribute": "Knob1", "Inverted": false }
There's no way to filter it out for the MIDI channel the message is on. So what if I want to have controls mapped to the same CC#, but for different MIDI channels?
Am I correct in assuming that in such case, I need to manually do MIDI automation in
on controller
?If so, here's what I know for sure: the function is very simple, it checks the array where all the mappings are stored, checks for the channel, and executes the appropriate code. This is where I see two paths:
- store the function in an external file, import it in both the interface processor and another MIDI processor. The interface processor needs to deferred and the function will just update the graphics in the UI. The other processor does the actual realtime stuff of changing network parameters etc.
or
- call the function directly in the interface on_controller callback and just call .changed() for the target controls, relying on their callbacks to do the realtime processing. In this case the interface script can be deferred.
It mainly pertains to the deferring of the interface script, as I don't fully understand how it works. The docs say
Defers all callbacks to the message thread (midi callbacks become read-only).
- Does this include the control callbacks?
- Is this only useful when one needs to use on note, on controler callbacks to do UI stuff?
-
@aaronventure Have you checked in the source code to see if adding MIDI channel to the automation object is possible? That would seem like the best solution to me.
-
@d-healey I'm severely lacking in that area and would definitely like to improve. I found this https://github.com/christophhart/HISE/blob/0bf3e5c096504bdfd08c109fb91e10e28fac51c9/hi_core/hi_core/MainControllerHelpers.cpp#L305
this looks like the MidiAutomationObject. I have no clue what to do from here.
Is there any real danger to having 10 CCs * 16 channels triggering on controller? The same thing would be happening with the Midi automation but I suspect that the hisescript callback will have bigger overhead?
-
@aaronventure said in Proper MIDI automation of controls across multiple MIDI channels?:
Is there any real danger to having 10 CCs * 16 channels triggering on controller?
That's unknown territory for me so I would suggest you try it and report back - or wait for Christoph.
-
If the MIDI automation system gives you everything except for using the MIDI channel as filter then I‘d recommend to keep on nagging me to add this - it should be a pretty easy addition with another simple check.
-
@Christoph-Hart But I'm nagging you on 2 fronts already (ScriptNode stuff and Faust channels), and was about to open up another thread...
Alright, can you add this please? I think it's an advanced enough thing where you don't have to modify the built in right-click MIDI learn system, so any implementation of this would have to be custom anyway. Therefore the automation object should just check for the MIDI channel on incoming controller messages.
This also plays in with exclusivity - setExclusiveMode should then be set to off for this to work, no? Also, will the message be consumed by controller number or as an object, i.e. will setConsumeAutomatedControllers also have to be set?
-
Yes so basically you would need another call
MidiAutomationHandler.setUseMidiChannels()
and then it will also take into account the channel of the incoming MIDI message when learning is active (or if you pass in a custom JSON object you can just supply the channel you want). -
@Christoph-Hart that sounds great.Thanks a lot.
Do you think there's a performance difference doing it this way and having a branch in on controller?
-
Do you think there's a performance difference doing it this way and having a branch in on controller?
Not relying on the script and doing stuff in C++ is always faster.