[feature request] Midi broadcaster
-
A broadcaster that is triggered by incoming MIDI.
Example use case:
I have a list of articulations on the UI. When a "keyswitch" is pressed I change the selected articulation displayed in the list. This is managed from an "Articulation Handler" namespace.
My current solution is to call the necessary function in the articulation handler from the on note on callback. But it would be nice if the behaviour could be self-contained within the namespace and the note on callback didn't need to be aware of the articulation handler's existence.
-
@d-healey is it just about avoiding one function call in on note or do you have a bunch of logic in on note for it as well?
-
@aaronventure In on note on I call
articulationHandler.onNoteOn()
which handles all the necessary stuff for updating the UI. This is just one example, I also have a similar call in on controller, for my guitar stuff I have similar things.Basically anything that responds to MIDI input currently has to be called directly from the MIDI callbacks, I'd like to see an observer pattern option as this is the way HISE seems to be going in general and it's making things so much more modular.
-
@d-healey the only problem I see with that is maintaining control of execution order, which at the moment is very clear along the entire tree
-
@aaronventure Broadcasters have a priority setting for this purpose. But most of my modules are independent and the order doesn't matter.
-
@d-healey no I mean I relation to other script editors. Currently a note on starts at the top, goes through all the sibling processors, then spreads to the children but still executes in order.
Where does the broadcaster fit in? Before the processor where it's defined? After? Maybe that would be one of the arguments when creating it.
-
So Broadcaster.attachToMidiMessage(executeBefore) with the function argument defining message type (0,1 or 2), number, value, channel
-
@aaronventure Oh I understand now, that wouldn't be affected at all. The broadcaster only exists within the script processor in which it is declared.
It's like having multiple on note on callbacks in a single processor.
-
@d-healey of course, but does it go before or after the processors bote/controller call backs?
Maybe you want it to go before so that all on note calls assume the articulation is already set and can refer to the variables? Maybe you want it to go after, just in case there's something else happening specific to this instrument where you want to ignore a note on so that it doesn't trigger the articulation?
-
@aaronventure I would expect it to work in the same way as component value broadcasters and component control callbacks. - I've never tested which triggers first. I think after the callback would make the most sense.
Edit: I just did the test with the value broadcaster and it fires before the component control callback, but I think for MIDI messages it makes sense for the callback to fire first - although I haven't given it much thought.