[Solved] Bitwig sending weird NoteOn/Offs

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 :wink: