I have a situation which I can’t make sense off: I have four latched notes in Bitwig. I made this graphic to show what values are sent vs. what I would expect:
As the sequence weirdly ends on a NoteOn, I am stuck with a linguring note. Can anybody make sense of this?
I tried the same with Helm Synthesizer. It seems to handle the situation well, as in it doesn’t have linguring notes. I have no insights on the midi events though.
Are you aware the “Note on” with a velocity of 0 is equivalent to a “note off”?
No I’m not. But you mean equivalent as in “usually interpreted by synths as” and not as “literally the same signal” I guess?
No, I mean it as in “a note on with a velocity of 0 is a note off”. That’s the MIDI standard for you. Lots of weird quirks.
Wanna know some other quirks? In order to save bandwidth (MIDI is sent via a 31250 bits per second port), successive messages are actually missing their command.
So all midi-messages start with a number that has the highest bit set, right? Wrong.
It’s perfectly valid MIDI to send the following sequence:
0xB0 0x01 0x43 0x01 0x61 0x01 0x73
It’s sending midi-CC in channel 0, for mod-wheel, value 67, then mod-wheel 97, then mod-wheel 115.
You’re just lucky that VST/AU/AAX is basically repeating the last controller / note on / pitch-bend command for your convenience.
Simply treat a note on with velocity zero as if you’ve received a true note off instead and your problem will go away.
Ok that’s interesting stuff. However, I am using the juce functions
bool MidiMessage::isNoteOn(bool returnTrueForVelocity0 = false) const
bool MidiMessage::isNoteOff(bool returnTrueForNoteOnVelocity0 = true) const
with those default params being ommited. Therefore the issue you mention shouldn’t be a problem.
I noticed however that this behaviour is not happening with an older version of my plugin. So chances are that I broke something or something is broken in JUCE6 (the old version is built on 5.4.7).
Yeah, we don’t use those functions. We simply use a switch/case on the raw midi-data. It’s very old code we simply call from within the appropriate juce functions.
Ok, found the culprit: JUCE6 deprecates the MidiBuffer::Iterator, so I rewrote that part with a MidiBufferIterator. In the process I made such an error that no two consecutive messages within a single buffer are processed. I didn’t realize this while testing with my keyboard.
I guess I gotta work on those keyboard skills then 
