Chico,

Early in the receive process you mask off the least sig. nibble. Because of this, your test of the accumulators least sig bit is pointless as you will always fall thru to ProcessMidiData. You will then process based upon either the previous byte being a Note On/Off msg. or an initialized or random value.

Imagine MIDI Running Status. How would that perform with the existing code? This could be an alternate reason for you situation where differing host data streams perform differently, depending upon if they issue 3 byte MIDI or 2 byte Running Status pairs.

A technique that i've used allocated a flag for "MIDI SYNC". To achieve MIDI SYNC you must receive a MIDI Status byte you support. You store this for comparison with future Status bytes and any non-Status bytes received are interpreted as NOTE/VELOCITY (data1/data2) pairs.

Real Time Status bytes can intervene within valid Status exchange so if you don't support them one way of handling them is to drop them on the floor at time of receipt. In any case they don't impact MIDI SYNC.

Another thought, handle msg parsing and framing in the foreground and just buffer MIDI in interrupt. This allows more headroom for message handling with payback a direct function of how verbose your MIDI Host is and/or how quickly your processor executes code.

regards,
p