Hi @Dr-Dawg I'm sorry it took longer.
I will try to organize my workshop again to test the stuff.

@ All
Maybe someone is willing to test the new exciting feature in the meantime?

Hi @Dr-Dawg I'm sorry it took longer. I will try to organize my workshop again to test the stuff.

@ All Maybe someone is willing to test the new exciting feature in the meantime?

Hi @baldram, glad to hear from you. No need to hurry, take your time. I'm sure someone will look over this as soon as he wants to use Midi features together with the library.

Fetched the latest library changes and changed the order of switchToMp3Mode and loadDefaultVs1053Patches in docs and two examples.

I had some major issues with lost notes. The following logic was resolving my issues

void VS1053::sendMidiMessage(uint8_t cmd, uint8_t data1, uint8_t data2) {
    int len = 4;
    uint8_t data[6] ={0x00, cmd, 0x00, data1};
    // Some commands only have one data byte. All cmds less than 0xBn have 2 data bytes 
    // (sort of: http://253.ccarh.org/handout/midiprotocol/)
    if( (cmd & 0xF0) <= 0xB0 || (cmd & 0xF0) >= 0xE0) {
      data[4]=0x00;
      data[5]=data2;
      len = 6;
    } 
    sdi_send_buffer(data, len);
}

Hey @pschatzmann so you tested the implementation. Sounds exciting! It's high time to merge this PR.

What was the hardware you used (the ESP board and VS chip)?

@Dr-Dawg what do you think about the eventual adjustment?

The test was with an ES1002 based board and a cheap ESP32 devkit clone.

So finally someone had a use for the MIDI code! :-)
@pschatzmann it's great you tested it.
The basic difference to me seems to be using sdi_send_buffer instead of SPI.write for the 4-6 bytes.
I.e. sdi_send_buffer includes data_mode_on/off, await_data_request and SPI.writeBytes
If it works, I'm fine with it, unfortunately right now I don't have the hardware setup nor the time for testing..

Anyway one should keep in mind, I encountered issues with VS1003 for some reason sometimes DREQ being ALWAYS down.
This might cause problems (infinite loops), with both versions of sendMidiMessage when using await_data_request .

@pschatzmann What data did you use to observe "lost notes"? Is it enough to use any basic example?

I did my own example using my own API just playing notes: https://github.com/pschatzmann/arduino-audio-tools/blob/main/examples/examples-vs1053/streams-midi-vs1053/streams-midi-vs1053.ino
About after playing the first few notes properly the key off messages somehow got lost and it started to play additional notes w/o stopping the earlier ones...

So finally someone had a use for the MIDI code! :-) @pschatzmann it's great you tested it. The basic difference to me seems to be using sdi_send_buffer instead of SPI.write for the 4-6 bytes. I.e. sdi_send_buffer includes data_mode_on/off, await_data_request and SPI.writeBytes If it works, I'm fine with it, unfortunately right now I don't have the hardware setup nor the time for testing..

Anyway one should keep in mind, I encountered issues with VS1003 for some reason sometimes DREQ being ALWAYS down. This might cause problems (infinite loops), with both versions of sendMidiMessage when using await_data_request .

Just for sake of documenting this weird issue, the DREQ constantly low is a known bug in a older version of the RTMIDI patch for VS1003. My code would hang after changing the 0xA register to 0x30 because it was waiting for the DREQ permission to be down. Initialy I attempted to override the awaits without much success but then I found a more recent version of the firmware in the VSLI website that worked. However for some reason, it only worked after I sent it using the legacy version with two arrays containing registers and bytes instead of the compressed version.

I tested it using an Arduino Mega with a VS1053/VS1003 LC Electronics board.

Thanks a lot for the clarification, @varlen !
So I probably switched patches without notifying..