Open weshi opened 1 year ago
Hi, to be honest i had no chance to play with midi too much, as i am not an expert. Only tests i remember were with android smartphone, but i dont remember what or how it worked.
Thank you for the quick reply @chegewara.
I did futher investigation and testing, and figured out that it was caused by the way function tud_midi_stream_write was called. Let's take noteON for example:
In your current version, it's defined as:
void MIDIusb::noteON(uint8_t note, uint8_t velocity, uint8_t channel) { log_v("ON: %d\n", note); uint8_t buf[] = {0x90, note, velocity}; tud_midi_stream_write(channel, buf, 3); }
I looked at the definition of tud_midi_stream_write, the first parameter is: uint8_t cable_num;
I'm not sure what's the definition of this cable num, but if I always pass 0 to it, and OR the channel value to the status byte (i.e., buf[0]), then it worked correctly:
void MIDIusb::noteON(uint8_t note, uint8_t velocity, uint8_t channel) { log_v("ON: %d\n", note); uint8_t buf[] = {(uint8_t)(0x90 | channel), note, velocity}; tud_midi_stream_write(0, buf, 3); }
Thanks, Wenbo
Hello, I would like to ask if this correction has already been implemented, as I am facing the same issue where when I try to use channels other than the default one, the MIDI information transmission fails. Thank you.
In my case the Windows PC recognises the midi device, but no notes are sent, when i call midi.noteOn(), does anyone have this prob?
Hello,
When I tried to use the MIDIusb class to send notes (by calling the noteON) with different values of channels, it seems that it only worked for channel 0. Is this a known issue?
Thanks, Wenbo