如何用 Web MIDI 防止 1983 年的合成器崩溃？

背景

现代浏览器运行在高性能硬件上，处理器主频以 GHz 计，支持多线程操作，并能以毫秒级速度加载 GB 级别的数据。然而，当我们将这种现代技术应用于复古硬件时，往往会遇到巨大的兼容性挑战。

以 1983 年发布的 Yamaha DX7 合成器为例，其内部搭载的是运行频率仅为 2 MHz 的 8 位 Hitachi 6305 微处理器，且仅拥有 256 字节的 RAM 缓冲区。当试图通过现代 Web MIDI API 将浏览器与这类复古设备进行桥接时，开发者会直接撞上一个经典的复古计算瓶颈：缓冲区溢出。如果数据发送速度过快，合成器的 CPU 可能会挂起、丢包，甚至完全损坏内部的声音存储器。

核心内容

速度差异与硬件瓶颈

在 20 世纪 80 年代，MIDI 物理硬件通过电流环路运行，波特率为 31,250 bits per second（bps）。虽然速度缓慢，但带宽是恒定且可预测的。

如今，大多数计算机音乐设置使用现代的 USB-to-MIDI 适配器。现代计算机以极快的速度发送 USB 数据包。廉价的、无缓冲的适配器在高 USB 带宽下接收数据，并立即尝试将其序列化并通过 MIDI OUT 引脚倾倒出去。

由于标准 MIDI 协议缺乏硬件握手线路（没有 RTS/CTS 引脚），DX7 等复古设备无法在物理层面上告诉浏览器：“嘿，停止发送数据，我现在正在将最后一个预设块写入 SRAM。”这种缺乏流控机制的现状，使得直接控制复古硬件成为一项“绝对的时间噩梦”。

软件层面的流控解决方案

为了解决 JavaScript 中的这一问题，开发者必须实施自定义的软件流节流机制。核心思路是将数据分块发送，并在每个数据块之间插入延迟，以便复古 8 位 CPU 有时间将数据块写入 EEPROM。

以下是一个实现 SysEx（系统独占消息）传输分块和节奏控制的 JavaScript 示例：

// 分块和节奏控制 SysEx 传输
async function sendSysExWithPacing(midiOutput, rawSysExBytes) {
  const CHUNK_SIZE = 256; // 限制块大小以防止缓冲区洪水
  const INTER_CHUNK_DELAY = 60; // 数据包之间等待的毫秒数

  for (let i = 0; i < rawSysExBytes.length; i += CHUNK_SIZE) {
    const chunk = rawSysExBytes.slice(i, i + CHUNK_SIZE);
    midiOutput.send(chunk);
    // 等待，允许复古 8 位 CPU 将块写入 EEPROM
    await new Promise(resolve => setTimeout(resolve, INTER_CHUNK_DELAY));
  }
}

数据解码的复杂性

一旦建立了可靠的硬件通信链路，下一个障碍是数据解码。在 80 年代，MIDI 规范定义了如何触发音符，但将系统独占（SysEx）参数格式完全留给制造商自行定义。这意味着每一台复古合成器都有自己未记录的、专有的字节结构：

• Yamaha DX7：输出恰好 4104 个字节（6 字节头部，4096 字节参数数据，1 字节校验和，1 字节停止字节）。32 个语音槽中的每一个的最后 10 个字节包含代表补丁名称的 ASCII 数据。
• Roland Juno-106：甚至不支持远程转储请求。该合成器仅在手动提示时才会说话：用户必须物理按下面板上的 'WRITE' 键来流式传输其当前补丁内存。
• Korg M1：使用打包的 7 位架构。由于 MIDI 状态字节必须将最高位设置为 0，数据字被分组为 7 个一组，第 8 位被解包并单独附加。开发者不得不编写自定义的位移位数组解码器在 JS 中解析这些字符。

浏览器安全限制

由于 Web MIDI 允许网站刷新固件或直接向外部物理 USB 硬件写入原始系统独占字节，浏览器对此采取了极严格的安全措施：

• Google Chrome 和 Microsoft Edge：要求通过权限获得明确的用户批准，才允许网站通过 MIDI 进行通信。
• Safari 和 Firefox：出于对指纹识别和硬件注入漏洞的谨慎，完全阻止了 Web MIDI API。

关键要点

• 硬件代差巨大：现代 GHz 级处理器与 2 MHz 8 位复古 CPU 之间存在巨大的速度鸿沟，直接连接会导致缓冲区溢出和数据损坏。
• 缺乏硬件握手：标准 MIDI 协议没有 RTS/CTS 等硬件流控引脚，复古设备无法物理通知主机停止发送数据。
• 软件节流是必要手段：必须通过 JavaScript 实现自定义的分块发送和延迟等待机制（如 setTimeout），以匹配复古硬件的处理速度。
• 专有协议碎片化：不同品牌的合成器（如 Yamaha、Roland、Korg）拥有完全不同的、未公开的 SysEx 数据格式，需要编写特定的解码逻辑。
• 浏览器安全壁垒：出于安全考虑（防止指纹识别和硬件注入），主流浏览器对 Web MIDI API 有严格的权限限制或完全封锁。

意义与影响

这篇文章揭示了复古计算与现代 Web 技术结合时的深层技术挑战。它不仅仅是一个关于 MIDI 协议的技术笔记，更展示了如何在缺乏硬件支持的情况下，通过纯软件手段解决底层时序问题。

对于音乐科技开发者而言，这提供了在浏览器中直接控制 vintage 硬件的关键方法论：尊重硬件的物理极限，通过软件抽象层模拟流控。

此外，文章末尾提到的 knob.monster 项目，展示了这一技术探索的实际应用价值。通过构建基于浏览器的工具，取代过时的、未签名的桌面实用程序，开发者可以将复古合成器直接连接到浏览器标签页，实现云备份和现代化的预设管理。这不仅解决了技术痛点，也为复古硬件爱好者提供了更便捷、更安全的交互体验，推动了复古音乐设备在 Web 生态中的复兴。