Is there a sure method of blocking MIDI messages immediately?

[VirtualVirgin]

@d-healey said in Is there a sure method of blocking MIDI messages immediately?:

@VirtualVirgin said in Is there a sure method of blocking MIDI messages immediately?:

if (Message.getEventId() == eid)

This will always be true, so you don't need it.

This is just a test here,
but it is not always true if there is intervening code in between the initial variable declaration and the "if "statement of it.

If new notes are generated after the var eid = Message.getEventId();
in the script they should return a "false".

[VirtualVirgin]

@d-healey said in Is there a sure method of blocking MIDI messages immediately?:

@VirtualVirgin said in Is there a sure method of blocking MIDI messages immediately?:

So the Message.ignoreEvent(true) works, but not immediately.

The message is ignored as soon as you tell it to be, but the message still exists in the processor you ignored it in so you can still see its properties like the note number.

Ignoring just means it won't be processed any further in the chain, won't trigger sound generators, etc.

But if note numbers are still passing to be picked up by the Console at the point, then they will also be picked up if I am pushing Message.getNoteNumber() into a MidiList or an array. I do not want that.

[d.healey]

@VirtualVirgin said in Is there a sure method of blocking MIDI messages immediately?:

Message.getNoteNumber() into a MidiList or an array. I do not want that.

Can you show me an example where you would be adding it to a MIDI list so I can see the flow of your program?

[VirtualVirgin]

Here is a snippet of the test-

HiseSnippet 1143.3oc6X0sSabDEdFCCJdKUoQp2zb0pbkoBgV6Zv3FQKArchUhAqXBM2TEMd2w1SX8Lq1cLDqHd2pTeC5SReCnmY10dWCFJwhJUZwWf74+Oel47c1k1gRWVTjLDgsNZb.CgWkzYrPMX+ATt.0rFB+cjl8ExPlc2w10OkIT1MqYqXQJzdiCnQQLODFuzK0tiyuLx74O+48n9TgKKUEBcrj6xdCeHWkps8tul662f5wNhOLi2k2soqTruzWNBf1RDGT.08DZe1ATsa4HnWQiFfveOw0sbU118JUwoTU1ldk6VpnCsjS0pUXzMcb6VkQK0qqqCBuRcOtRF1QQAzCIcOo23NCjmIhKvw7HdWelVnHpCT4X0n8Gv88ZOoOEgPXR6zt1Rwcsukzh6wmpOs68MFC1oQjsogycSPp3W.jvYfzxwP5IjNtg7.UpEMd9JRSghE1iBmMYgRruH7uQ1WBNHTaLjdBqQHHLMfBa43rtM7m0dduQBWEWJrkhCjJ1ghBqY8Yq7VmaYeYS85MWa5xDJ88Ygy0r95P3MEXAwngcYgqaeJ0eDapivO+Y6oqb65otw+py3nTzTvUGFvRjaH88z8J82u5I.JosAe6cMqQUT8gRhNvu.VnhqgCtF6TXLH9HJOoFK5DkLv36v.oPmA7ppj6TwGJM7kTEWz+HN.aNffGSxppH5SSma18i6NNcH5m1MA.wUyh7Z13tRZnGpa+IiV4Wwyy6Bs2bEaXp1Kt3hmNq1RIpMNqXeRk57jIbyu6b+Jl7YKa6mAU6W3dpAO6GsKVdCm005pwiB7oiOzUQOkcf4DDLqBGwLlei7LHJPS4sMxuhGKVrTEi79ihTxguLjFLf6FAF5Q8ihCsFqGcju5EAALZnl5Iad2yGXOfT8VnqIACNarUUyms21oRUmJEMdcjreeeVKoGalLqGfgAZgf4qghQ26hXGybgqYYvxzpAFa3SUcTi8uTlZWexQvk0CWWCUoUozD80EdYp8VVmiNS2SARH7e.c7ALd+AJsTCCc5UXA.9Go2H.MyRJooqSL.SUyvDnG2EQb03rz4eALUN2HS0sEhOgzlqbGLeLlaNXDl29m.iI76eModudvAdJ.Wlz38KJY9su7O5ZVJupglFjXgEuK1CGbq2CiW597ZTm6n0nOlL8QgN5xOJTxpzbqiI1WydxSog1Ltm8N1sfbBOVyF8YJSFa5UXsmaYkm2ytv7rYuyN5HWyJOjl7S7fadBMiSEzzPPJxeNrPLObKIR5y1HHjClxjPMZh4eKrF38+91aStq1aemuq9AV1+GxxV59JK6x2iYYsHsZVqo8gilKAK92uV90Gn8df16AZu4V92JGoeywVTUHGdwQBLMzAncbYIulg9NHNm91RrriVV2A5vDdFA86.lXrnVFmXr3Di+moFCotgxO3FOAqYtdjQCzaEl+MT4Iszx1EQlo5r2WFBDoev0c1Tck.KsnA9CKZfkWz.2bQCbqEMvJKZfa+2GndO2KFojCiG+QH3UsMThXbcAEljLScn+BL0SNn

There is a Console.print for the onNoteOn of two MIDI script processors.

If the Message.ignoreEvent is on, then only the parent processor prints the note number.

If the Message.ignoreEvent is off, then they both print the note number.

So message is not being blocked immediately, as in the first condition, neither script processors should be printing anything onNoteOn.

[d.healey]

@VirtualVirgin But where would you be adding it to a MIDI list or array, where the Console.print line is?

[VirtualVirgin]

@d-healey The MidiList or array could be anywhere depending on what stage of note transformation is going on.

[d.healey]

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

[aaronventure]

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.

[d.healey]

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

[aaronventure]

@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

[d.healey]

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

[Christoph Hart]

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.

[aaronventure]

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

[Christoph Hart]

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