Parser is more simple now. It not evaluate the size of package twice.
Parser not check if a message is well constructed or not except first message of the package.
Parser can transform runningStatus messages to Full Midi messages. If #define RUNNING_ENABLE is commented, parser will add data like full midi messages.
FortySevenEffects MIDI serial parser respond identically to both method (runningStatus and Full), fortunately.
Previous size filter might add a 2-bytes full midi and other running status (other byte) like a 3-bytes full midi message wrongly. It may cause a bug depending if serial Parser accepts or not running status messages.
This commit removes that previous and unnecessary size filter but it still discriminte the size of message after this point:
2f48b0f25b/test/msvc/ConsoleApplication2.cpp (L78-L91)
If #define RUNNINGSTATUS_ENABLE is commented, it will transform all incoming runningStatus messages in full midi messages. Else, it will put in the buffer the same info that it had received (runningStatus will be not transformated).
I recommend not use runningStatus by default. Only use if parser accepts runningStatus and your application has a so high transmission rate.
Added runningStatus continuation after a timeStamp Low or a System message (0xF#)
I only have modificated the MSVS code, check it before you copy it to to BLEtransport.h
In the 2.0.0 release of the Arduino Mbed OS Boards platform, the mbed architecture split into four architectures:
- mbed_edge: Arduino Edge Control
- mbed_nano: Nano 33 BLE and Nano RP2040 Connect
- mbed_rp2040: Raspberry Pi Pico
- mbed_portenta: Portenta H7
The mbed architecture should be retained for backwards support, but the new mbed_nano should also be added to avoid spurious incompatibility warnings and the library's examples being shown under the File > Examples > INCOMPATIBLE menu of the Arduino IDE when the Nano 33 BLE board is selected.
Windows connection to ESP32, based on suggestion from @wakwak-koba (I get notes in the MIDIBerry input monitor using ESP32, but not using NimBLE ?? (MidiBle example)
Test multiple packets by sending sysex11 over a buffer of 5 bytes of more (change byte mTxBuffer[Settings::MaxBufferSize];)
Interesting edge cases are with buffer len: 5,7 and 12 (with sysex11)