Is there a sure method of blocking MIDI messages immediately?
-
@VirtualVirgin But where would you be adding it to a MIDI list or array, where the Console.print line is?
-
@d-healey The MidiList or array could be anywhere depending on what stage of note transformation is going on.
-
@VirtualVirgin Until I know where it is I can't suggest a particular solution, but if it's in the same list where you are ignoring the note, you can just not add it to the list if you are ignoring the note.
And if it's in a secondary script the note will never reach it if it's ignored so there shouldn't be an issue. Unless I'm misunderstanding - it's tricky without a real-world example.
-
That specific callback will always execute, the one where you called the ignore. Because it's a function and calling ignire doesn't prevent the execution of the function further (use return for that). But if you have any other sibling midi processors right after or child processors, the ignored message will not show up there.
Also, initializing variables inside the on note function is a big nono. Do it in on init.
-
@aaronventure said in Is there a sure method of blocking MIDI messages immediately?:
Also, initializing variables inside the on note function is a big nono. Do it in on init.
I think in this case changing the var to local would be sufficient.
-
@d-healey it's not an inline function, tho?
The thread guard is gonna be giving you a hard time about it on every note you press
-
@aaronventure Local variables can be used it the default callbacks, even though they are not inline functions. I haven't had any issues with this when using them to store and manipulate values that are already within the callback, such as Message properties. I assume the HISE compiler will swap them out for their actual value- or do some other magic.
-
I think in this case changing the var to local would be sufficient.
This.
local
variables can be used in both inline functions and inbuilt MIDI callbacks and will not allocate any memory for simple types (numbers).HISE compiler will swap them out for their actual value- or do some other magic.
No, it just preallocates the storage when compiling the callback.
-
@d-healey Wow that's actually great, somehow I missed this. Nice!
It was a bit annoying having to go back and declare a few variables just for carrying data throughout the function, but I guess I had just unquestioningly accepted it and never wondered why there wasn't an easier way of doing it.
Pretty silly on my end, in retrospect. I guess I was just cucked by the Thread Guard which stopped me from having any super bright ideas about memory stuff from within the realtime callbacks.
-
@aaronventure better safe than sorry :) but yes, the requirement for non-allocating local number variables was one of the first things I hacked into the scripting engine.