MidiMessage::ControllerEvent() wrong status byte?

General JUCE discussion
1

Hi Everyone,

I’m trying to work out the control flow from a midi device and in parsing a message from the device I’m looking to use the JUCE MidiMessage::controllerEvent() function.

The function definition is:

MidiMessage MidiMessage::controllerEvent (const int channel, const int controllerType, const int value) noexcept
{
    // the channel must be between 1 and 16 inclusive
    jassert (channel > 0 && channel <= 16);
  
    return MidiMessage (MidiHelpers::initialByte (0xbC0, channel),
                        controllerType & 127, value & 127);
}

Which refers to the MidiMessage constructor definition:

MidiMessage::MidiMessage (const int byte1, const int byte2, const int byte3, const double t) noexcept
   : timeStamp (t), size (3)
{
    packedData.asBytes[0] = (uint8) byte1;
    packedData.asBytes[1] = (uint8) byte2;
    packedData.asBytes[2] = (uint8) byte3;
    
    // check that the length matches the data..
    jassert (byte1 >= 0xf0 || getMessageLengthFromFirstByte ((uint8) byte1) == 3);

//(Note from OP: If you're wondering how the three-argument function refers to the 4 argument defintition, I was too and it seems to just set t=0 automatically)
}

…and MidiHelpers::initialByte():

 inline uint8 initialByte (const int type, const int channel) noexcept
 {
   return (uint8) (type | jlimit (0, 15, channel - 1));
 }

The issue that I’m having is that the argument byte1, which I believe refers to the MIDI status code, is coming in as 192, as the result of MidiHelpers::initialByte(0xbC0, 0) appears to be 192. According to the MIDI specification here, 192 is the status byte for a PROGRAM change message on channel 0, not a CONTROL change. Then, the the result of getMessageLengthFromFirstByte(192) is 2, not 3, and this fails the assert. It’s not an issue in a release build of my code because the message DOES have three bytes, but it’s messing with my debugging.

Should the value of the first argument of MidiHelpers::initialByte actually be 0xbC0 ?? Is this a mistake in the JUCE library or am I missing something else here??? Thanks!!

–Marc

2

This sounds like the problem. controllerEvent Is for creating a MIDI message from scratch, not for parsing incoming data. I can’t quite imagine what the data flow looks like in your approach. Is this in a plugin or an app?

3

Well a byte cannot be 0xbC0 (3008). Has that code been overwritten (should be 0xb0)?

1 Like
4

It seems that your copy of JUCE has been modified. Both ‘master’ and ‘develop’ show ‘0xb0’ used in ‘MidiMessage:: controllerEvent’.

1 Like
5

Thanks all! It’s possible that what seems to be the correct byte (0xb0) was overrwritten with an errant keystroke somewhere. I don’t see it in my git history but who knows. 0xb0 would be the correct value for a CC message on channel 1 so that sounds right!

6

Did you use the git ‘blame’ command to check?