ETC missing MIDI note triggers occasionally


Occasionally, the ETC seems to missing the MIDI note trigger flag (etc_midi_note_new OR etc_midi_note). I’m firing off MIDI notes from my iPad, through an external MIDI interface to the ETC.

I have reproduced this from multiple apps on the iPad (Auria Pro, Cubasis) and using multiple interfaces (Zoom U24, generic USB to MIDI cable).

8 of my 10 custom modes work flawlessly. Two of them inconsistently trigger MIDI notes in key sequences. It isn’t anything too complicated (firing off MIDI note #14 nine times in a row at 1/16th note intervals, 120 BPM).

Maybe it’s my implementation, but that doesn’t quite explain why it works 9 times out of ten.

Will the ETC OS see any updates or performance improvements? I have a sneaking feeling that it’s just missing the occasional NOTE message.


I think the problem is the scan rate of 30 frames per second. This means we have 33 milliseconds for each frame. I am quite sure, that the MIDI reader only gets some part of this time for reading - lets assume the half: 15ms.
This would mean: If your MIDI note command is shorter than 15ms, then it may not be recognized while the second half of the frame duration. This may happen especially with drum trigger notes, because those usually are only 1ms long (the note-off command comes immediately after note-on command).

So the workaround is: you have to provide notes that are always longer than 30ms.

The same problem exists with MIDI-Clock which does not work reliable at all at higher speeds. I made a test mode that displays a rectangle for each clock tick. You can watch how the interference between the video frame rate and the midi clock speed causes patterns in the missing rectangles.


hmm, that’s kind of the problem , but not quite…

yes, the midi queue is only queried once per scan rate. but afaik , it will queue all messages - so they are not lost

the issue is your only parsing these messages once in that scan cycle, so often its overwriting the data , so your missing data (including transitions)

theres really 2 solutions…
a) do more frequent polls, so detach scan rate from midi polls, which seems reasonable to me :wink: , but you ensure you do not do graphics work , as that implies more cpu/gpu load
b) store events so you can process them all, rather than compress/quantise them.


I’ve tried making the notes longer and that didn’t work. It seems as if the ETC is missing the “note on” and if the note is just held longer, the ETC will still have missed the “note on” message at the start. This may be in how the ETC relates NOTE_ON to NOTES_NEW … I’m not sure.

AS the detaching the scan rate from the draw function … I may try that next and call another function in my mode that parses the note_new and note_on data constantly and then drop that into the draw function.

Thanks for the thoughts!