Fix: MIDI parser — System Real-Time no longer corrupts running status

[sauloverissimo]

Summary

System Real-Time bytes (0xF8–0xFF) can legally appear anywhere in a MIDI byte stream — even between data bytes of a multi-byte message — and must not affect the parser's running status. The current parser handles them inside the ParserEmpty switch case, which means they first trigger a state reset (pstate_ = ParserEmpty) and overwrite incoming_message_ fields. This causes:

1. Channel corruption — a Timing Clock (0xF8) between NoteOn bytes shifts the channel to 8 (since 0xF8 & 0x0F = 8)
2. Lost messages — the in-progress multi-byte message is destroyed
3. SysEx corruption — RT bytes inside SysEx are stored as data instead of being dispatched

This is the root cause of #666 and #665.

The fix

Move System Real-Time handling to the very top of Parse(), before any state modification:

if(byte >= 0xF8)
{
    if(event_out != nullptr)
    {
        MidiEvent rt_event;
        rt_event.type    = SystemRealTime;
        rt_event.channel = 0;
        rt_event.srt_type = static_cast<SystemRealTimeType>(byte & kSystemRealTimeMask);
        *event_out = rt_event;
    }
    return true;
}

Uses a stack-local MidiEvent so pstate_, incoming_message_, and running_status_ are completely untouched. The early return means RT bytes are transparent to the rest of the parser — exactly as the MIDI 1.0 spec requires.

Tests

Added 4 new unit tests covering the scenarios that the existing runningStatSysRealtime test does not:

Test	What it covers
sysRealtimeMidMessage	Clock bytes interleaved within a NoteOn (between status/data0/data1)
sysRealtimeDuringSysEx	Clock byte inside a SysEx message — must not corrupt SysEx data
allSysRealtimeTypes	All 8 RT types (0xF8–0xFF) parse correctly with channel=0
runningStatusPreservedAfterRealtime	Running status NoteOn + RT + channel verification across multiple notes

All 154 tests pass (including the existing runningStatSysRealtime test).

Related

• Closes Midi In Clock not supported #666
• Closes Midi NoteOn Velocity 0 wrong channel #665
• Re-resolves MIDI - Clock messages may interfere with running status implementation #422 (the mid-message case was not covered by the original fix)
• Complements PR Feature: Midi - make it possible to handle 'SystemRealTime' events synchronously #643 (synchronous RT callback) — that PR adds a callback feature at the MidiHandler level, but the underlying parser bug still exists without this fix

[github-actions]

Test Results

154 tests  +4   154 ✅ +4   0s ⏱️ ±0s
  1 suites ±0     0 💤 ±0 
  1 files   ±0     0 ❌ ±0 

Results for commit 4ed3992. ± Comparison against base commit 9498417.

[stephenhensley]

Nice! This looks good at a glance.
I'll be looking at a few PRs this coming week, and will give this a test along with the related system realtime improvement PR.

Thanks for the contribution!

[sauloverissimo]

Thanks @stephenhensley! Let me know if you need anything or if I should make any adjustments. 🌟

[stephenhensley]

@sauloverissimo Everything looks good to me.
Everything tests fine with no observable regressions while running a few programs on hardware accepting MIDI via UART from my computer.
The tests show good coverage of the things you fixed, and should catch any regressions that would reintroduce similar issues in the future.

I'll be testing the related system-realtime PR w/ the optional callback on top of this.
It seemed practical to test/merge yours first since it has test coverage, and passively resolves existing issues, while the realtime callback is opt-in only.
I expect that to work well alongside this update, and to be merged shortly unless any issues come up.

Thanks again for the contribution!