Proper MIDI automation of controls across multiple MIDI channels?

[aaronventure]

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?

[d.healey]

@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.

[aaronventure]

@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?

[d.healey]

@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.

[Christoph Hart]

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.

[aaronventure]

@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?

[Christoph Hart]

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).

[aaronventure]

@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?

[Christoph Hart]

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.

[aaronventure]

@Christoph-Hart Nag nag

If C++ is always faster, then it would be paramount to avoid a large branching function in on_controller when multiple MIDI channels are in play, as that by itself means there's a lot of controller data being sent into the plugin, no?

Can you please add the proposed MIDI channel property to the automation object?

[VirtualVirgin]

@aaronventure I would like to see this added to the MIDI learn function. As it is I can't use the built-in MIDI learn because it will respond to all MIDI channels of the learned CC, and with a multi-timbral setup (such as an orchestral template in a DAW) this is a no-no.

[d.healey]

@VirtualVirgin Does this happen also if you filter the MIDI channel using the settings floating tile?

[VirtualVirgin]

@d-healey said in Proper MIDI automation of controls across multiple MIDI channels?:

@VirtualVirgin Does this happen also if you filter the MIDI channel using the settings floating tile?

So I think this is what you are asking about.
The know here has been MIDI learned using CC#1 on Channel 1, and I am moving a knob on my MIDI controller sending CC#1 on Channel 2.

The Channel Filter has no effect here on the MIDI learn input.
Even if it did, it wouldn't be very useful as you would still want other channels to pass though to get to their desired destination,
To work properly, the MIDI learn itself needs channel detection and a "Channel" column needs to be added to the floating tile so the user can change it if need be.

[d.healey]

@VirtualVirgin said in Proper MIDI automation of controls across multiple MIDI channels?:

To work properly, the MIDI learn itself needs channel detection and a "Channel" column needs to be added to the floating tile so the user can change it if need be.

Ah ok, yeah that seems like a better solution. Is there a situation where you would want multiple channels to control the learned control?

[VirtualVirgin]

@d-healey said in Proper MIDI automation of controls across multiple MIDI channels?:

@VirtualVirgin said in Proper MIDI automation of controls across multiple MIDI channels?:

To work properly, the MIDI learn itself needs channel detection and a "Channel" column needs to be added to the floating tile so the user can change it if need be.

Ah ok, yeah that seems like a better solution. Is there a situation where you would want multiple channels to control the learned control?

Not off the top of my head. I'm assuming that if the user wants to control the same set of controls from more than one device, then they will map those knobs/sliders to the same MIDI channel on the different devices. That remapping is not possible on every device however, so it all depends on how many options to add for what may be minimal use cases.

[aaronventure]

@d-healey having a multi instrument or multi layer setup offering a midi channel selection for each, as well as being able to set it to "omni" like in Kontakt where it then responds to all channels

So when passing a midi channel in the object, I guess an implementation would be where we can pass either a channel integer, an away of integers or a string saying "all", or -1 or whatever react to all, the way it is now (in case the implementation requires it to have a defined midiChannel property).