why midiEventPacket_t is a 4-byte struct?
Opened this issue · 4 comments
Hello, I am trying to understand why is it necessary to do something like 0x80 | channel in event.byte1 while we have already provided the message type 0x08 in event.header.
Also by doing an OR between an 8bit channel byte does not protect from errors like this 0x80 | 16 where the message type part 1000 (Note Off) will be overwritten and become 1001 (Note On) and the program will compile without any warnings.
Could this OR operation be done inside the library in a more controlled manner to avoid such errors and also to expose only 3 bytes to the user instead of 4?
Thank you in advance.
this structure is packed and optimized to fit a 32-bit dword aligned data for the USB controller, midi define various length messages most popular being 3 bytes (e.g. note on/off), real-time message can be 1 byte, and sysex messages can be tens to thousands of bytes depending on the manufacturer.
Logical operations could be also achieved by defining a c bit structure elements inside a union data structure, but it does not really matter as long as the API provides functions to create these packed structures for you.
So the 32-bit packet in Figure 8 is represented with midiEventPacket_t struct, right?
I am confused because in the examples, the channel (I guess this is the cable number) is passed to second byte instead of the first one (header).
void controlChange(byte channel, byte control, byte value) {
midiEventPacket_t event = {0x0B, 0xB0 | channel, control, value};
MidiUSB.sendMIDI(event);
}
I admit, I have not read the protocol specification. I have read this one which shows only 3 bytes in total and it makes more sense to me. Sorry if this is not the place to ask these questions.
By the way, I don't have any issues with the library. It works fine.
Thanks again.
Here's a link to the USB MIDI 1.0 spec.
https://usb.org/document-library/usb-midi-devices-10
At the possible risk of repeating myself, I'd recommend you start reading at page 16.
