Re: Conflict with controllers in Ableton? FCB1010 midi mapping works then fails


On Thu, Apr 2, 2020 at 03:00 PM, EJ SHELDON wrote:
Are you saying that in MIDIOX, the HEX message correctly shows NOTE ON while the translation shows NOTE OFF, and HEX also shows a correct VELOCITY value of 0 while the translation shows an incorrect value of 64?
Hi EJ,

indeed, the HEX messages shown in MIDI-OX are correct, there are no bugs. It's not difficult to speak HEX, and it's good to learn those details if you want to monitor MIDI messages, MIDI-OX is the perfect tool for that : 
there's an overview table of all MIDI status messages here : 
NoteOn = 0x90 , NoteOff = 0x80, ControlChange = 0xB0, ProgChange = 0xC0   (0x... means HEX)
The lowest number of the status message byte contains the MIDI channel, which can go from 0x00 to 0x0F  (= 0 to 15), therefore a NoteOn status message can be 0x90 (for MIDI channel 1) to 0x9F (for MIDI channel 16)
NoteOn and NoteOff are 3-byte messages (status, data1 = NoteNumber, data2 = velocity). The date values are between 0 and 127, or 0x00 and 0x7F in HEX.
That's what you see in the MIDI-OX screenshot I posted :
90 64 7F = NoteOn notenumber 100 Velocity 127  (0x64 HEX = 6 x 16 + 4 = 100 decimal) 
80 64 7F = NoteOff notenumber 100 Velocity 127
90 64 00 = NoteOn notenumber 100 Velocity 0, which is correctly "translated" by MIDI-OX as a NoteOff event. 
Your MIDI-OX screenshot shows the same thing, but in decimal : 
144 1 100 = NoteOn notenumber 1 velocity 100
144 1 0 = NoteOn notenumber 1 velocity 0, correctly translated to "NoteOff"
144 56 127 = NoteOn notenumber 56 velocity 127
128 56 127 = NoteOff notenumber 56 velocity 127
The incorrect value of 64 is not in the MIDI-OX screenshot, but in the Ableton MIDI monitor. Since the alternative NoteOff representation uses "velocity=0" to determine that it's a NoteOff, there is no actual key velocity available, and Ableton just displays a random "64" value. (the value is not relevant, I think not many synths take into account how fast you raise your fingers from the keyboard...)

Some more side info about these alternative NoteOff representations :  MIDI1.0 dates from the eighties, where bandwidth was much more of an issue than today. Therefore the MIDI spec added the concept of "running status" in order to decrease the serial data traffic where possible : when sending a large number of MIDI messages of the same type on the same channel (= same status message), it is not necessary to add the status byte to each message. When the status byte is missing, the receiver will just reuse the last status byte it received. This is typically used for expression pedals or pitchbend wheels, which indeed send a continuous stream of messages with varying value but identical status message. The number of transmitted bytes is decreased with 33% by using the "running status" concept. In order to have the same advantage when playing a synth, it was possible (and preferred) to use "NoteOn velocity 0" messages on key release, instead of real "NoteOff" messages. This way you got a message stream with identical status messages and the "running status" system could do its job.  Of course all this is completely irrelevant nowadays, but that's where it comes from.  
I happen to know all about Running Status because you need to take this into account when merging 2 MIDI streams (re-insert the missing status bytes where needed). Behringer failed to do that correctly in the FCB1010, resulting in lots of hanging notes when you route a synth through the MIDI IN of the FCB1010. This bug was the trigger for me to start working on the UnO firmware, since Behringer customer support just suggested me to buy an external MIDI merge device to solve the issue. 

Join to automatically receive all group messages.