MidiMessage noteOn issue

#1

I’m saving a step sequencer state and am using a isNoteOn call to see if my saved state event (serialized as hex data) is a noteOn event (after passing that data to MidiMessage ctor). Sometimes the sequencer has noteOn messages with velocity 0 and this code

bool MidiMessage::isNoteOn() const throw()
{
    return ((data[0] & 0xf0) == 0x90)
             && (data[2] != 0);
}

tells me it’s not a noteOn message, and that’'s wrong, it is a noteOn with velocity 0 (in practice a noteOff) however a normal noteOff (0x80) can be interpreted differently then noteOn (0x90) with velocity 0. I’m basing this on my favorite midi spec: http://atom.maczo.pl/~atom/stuff/tech/midispec.htm (Note-On Note-Off). Correct me if my wrong, but i think that only the first byte and the length should be check to tell if it’s a noteOn event. I guess noteOn with velocity 0 can still trigger envelopes/LFOs and modulate parameters using the velocity value.

#2

per the spec you linked “A Note On message that has a velocity of 0 is considered to actually be a Note Off message”

#3

yes but theese messages are different and a noteOn with velocity 0 is still a noteOn in any software/hardware sequencer.

the distinction should be made for a sequencer to show what state the current step is, if isNoteOn() will return false i’d have to show it as a noteOff message witch is not true, it’s a noteOn with velocity 0 and will give me different results (musicly) then a noteOff message. Note Off messages also have velocity values, and juce creates them with values always 0. That’s also wrong, because

static const MidiMessage 	noteOff (const int channel, const int noteNumber) throw ()
#4

I’ve been writing software that works with MIDI since the mid 90’s (Opcode, Digidesign, Emu, etc), and a NoteOn with velocity 0 is always considered a NoteOff. Your first quote simply reinforces the idea.

Notice the ‘(as a Note Off)’.

On the other hand, when dealing with MIDI messages outside the realm of their standard meanings, you can do whatever you want with a 0x9X 0xXX 0x00. But, you can’t call it a NoteOn, it’s just arbitrary data.

Regarding the velocity value of the NoteOff, you may be correct.

#5

a noteOn with velocity is still a noteOn. how each hardware/software treats that message depends on the idea behind it. JUCE is a programming library and in this situation it gives me bad results, i serialize noteOn data with velocity 0 and when the same data gets re-loaded i get noteOff data (because isNoteOn() returns false). This is wrong, i need to know thhat this was noteOn with velocity 0 and i need to update my GUI accordingly to this information. Also this document states that each hardware/software treats this type of data differently. And i know there are a lot of situations in witch a noteOn with velocity 0 treated as a noteOn will have a different meaning then a noteOff

  • if notes trigger LFOs
  • if notes velocity modulates other parameters (ex. filter cutoff)
    and so on.

This is why for me this is a bug. However i’m open for discussion.

#6

It’s absolutely not a bug, and having the word “bug” glaring out of your topic title is pretty unfair!

But it’s an interesting point, so I’ve added a parameter to isNoteOn(), which should keep everybody happy…

#7

allright i’m sorry for the “bug” words, i already took my sleeping pill when i was writing this :slight_smile:

and what about noteOff ? could you add the velocity parameter to it?

#8

Oh yes, forgot about that one.

#9