Was trying to work out why my code didn't like PC midi keyboards (i.e., BOME's mouse keyboard, lasi's MIDIKeyHook, etc.).
Seems instead of a conventional "note off" (0x80) they all send a "note on" (0x90) with 0 velocity.
Is there a particular reason this is chosen instead of sending a "note off" as outlined in the MIDI spec? Are there some common situations where note off commands cause problems?
Sorry if this is common knowledge, but a lot of this is new to me...
0 velocity note on = note off?
-
AdmiralQuality AdmiralQuality https://www.kvraudio.com/forum/memberlist.php?mode=viewprofile&u=83902
- Banned
- 6657 posts since 10 Oct, 2005 from Toronto, Canada
There's a thing in MIDI called "running status". Normally a MIDI message consists of a status byte (which always begins with the high order bit set to one: 1xxxxxxx), followed by 2 data bytes (which always have the high order bit set to zero: 0xxxxxxx).
The status byte is used to describe the type of message, there's one code for note-on, another for note-off, another for control change, etc...
Then the first data byte describes WHICH control or note has been changed. i.e. the CC# or the note #. Because we never use the high-bit, we get a range of 0 - 127.
And the second data byte describes the position of the control or the velocity of the note. Again we have a range of 0 - 127 (however for note velocities, zero is reserved to mean note off because...)
If a whole bunch of messages come through, all for the same status, MIDI has the ability to save a some bandwidth by leaving out the status byte. This is called "running status". And obvious use for it is when performing a control change, you can save 1/3 of the traffic on the MIDI cable by only sending the status byte at the beginning of the stream (note that this works only as long as the stream isn't interrupted by any other type of message status. As soon as another type of message comes through, the running status is broken).
And to take advantage of this for note data, a stream of note-ons and note-offs can be differentiated by the velocity value in the 2nd data byte, without needing to send a new status byte every time your performance switches from note-on to note-off.
So by the MIDI spec, you are required to treat a note-on with zero velocity exactly the same as you would a note-off.
Make sense? (Even I forgot the reason for this until a recent VST list discussion reminded me.
)
The status byte is used to describe the type of message, there's one code for note-on, another for note-off, another for control change, etc...
Then the first data byte describes WHICH control or note has been changed. i.e. the CC# or the note #. Because we never use the high-bit, we get a range of 0 - 127.
And the second data byte describes the position of the control or the velocity of the note. Again we have a range of 0 - 127 (however for note velocities, zero is reserved to mean note off because...)
If a whole bunch of messages come through, all for the same status, MIDI has the ability to save a some bandwidth by leaving out the status byte. This is called "running status". And obvious use for it is when performing a control change, you can save 1/3 of the traffic on the MIDI cable by only sending the status byte at the beginning of the stream (note that this works only as long as the stream isn't interrupted by any other type of message status. As soon as another type of message comes through, the running status is broken).
And to take advantage of this for note data, a stream of note-ons and note-offs can be differentiated by the velocity value in the 2nd data byte, without needing to send a new status byte every time your performance switches from note-on to note-off.
So by the MIDI spec, you are required to treat a note-on with zero velocity exactly the same as you would a note-off.
Make sense? (Even I forgot the reason for this until a recent VST list discussion reminded me.
)
-
- KVRAF
- Topic Starter
- 3623 posts since 5 Jan, 2006 from UK
Aha! Yes, that makes perfect sense to me. 
Many thanks for the thorough description, much appreciated! (and gives me ideas about optimising things a little bit in my program as well)
Many thanks for the thorough description, much appreciated! (and gives me ideas about optimising things a little bit in my program as well)
-
AdmiralQuality AdmiralQuality https://www.kvraudio.com/forum/memberlist.php?mode=viewprofile&u=83902
- Banned
- 6657 posts since 10 Oct, 2005 from Toronto, Canada
Also note, that for the VST interface, hosts should resolve the running status message for the plug-in (meaning they pack the previous status into the VstMidiEvent structure transparently to the plug-in).
I believe this must be required behavior, though I suppose it would be possible to put 00000000 into the status byte to signify running status. I can't say I've run into this anywhere though. Anyone?
(And yep, thanks Meffy.
)
I believe this must be required behavior, though I suppose it would be possible to put 00000000 into the status byte to signify running status. I can't say I've run into this anywhere though. Anyone?
(And yep, thanks Meffy.
)-
- KVRist
- 117 posts since 18 Dec, 2006
Heh, that was my thread. I just wondered this same thing two weeks ago. Nice recap of that info, AQ.AdmiralQuality wrote:(Even I forgot the reason for this until a recent VST list discussion reminded me. ;) )
-
- KVRian
- 522 posts since 19 Jul, 2007 from Netherlands
