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

# 如何避免 Web MIDI 让 1983 年的合成器崩溃？| knob.monster 来源：https://knob.monster/how-do-you-keep-web-midi-from-crashing-a-1983-synthesizer 工程 2026年6月23日 为什么为 1980 年代的 8 位 CPU 编写 Web MIDI 代码是一场绝对的时间噩梦，以及如何安全地直接从浏览器控制老式硬件的数据流。 现代浏览器运行速度飞快。你的系统处理器以千兆赫兹频率工作，能处理多线程操作，并在毫秒内加载千兆字节数据。而 1983 年**Yamaha DX7** 老式合成器内部的微处理器是 8 位的日立 6305，主频仅 2 MHz，配备区区 256 字节的 RAM 缓冲区。当你试图使用现代的 **Web MIDI API** 连接这两个时代时，你会直接撞上一个经典的复古计算瓶颈：**缓冲区溢出**。发送数据过快，合成器的 CPU 就会挂起、丢包，甚至完全破坏内部声音内存。 ## 1. 流控制的消亡（以及 5 美元线缆的问题） 在 80 年代，MIDI 物理硬件通过电流环路以 31,250 比特/秒的速度运行。虽然慢，但带宽恒定且可预测。如今，大多数电脑音乐设置使用现代 USB 转 MIDI 适配器。现代电脑以闪电般速度发送 USB 数据包。廉价的、无缓冲区的适配器以高 USB 带宽接收数据，然后立即尝试串行化并将其倾泻到 MIDI 输出引脚。 由于标准 MIDI 缺乏硬件握手线（没有 RTS/CTS 引脚），DX7 无法物理告知浏览器：“嘿，停止发送数据，我现在正将最后一个预设块写入 SRAM。” 为了解决这个问题，在 JavaScript 中我们必须强制实现自定义的软件流节流： ```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)); } } ``` ## 2. 厂商特定的十六进制解析器 一旦建立起可靠的硬件通信链路，下一个障碍就是解码数据。在 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 中编写自定义的位移位数组解码器，仅仅为了解析字符。 ## 3. 浏览器安全限制 由于 Web MIDI 允许网站直接向外部物理 USB 硬件刷新固件或写入原始系统专用字节，浏览器对此予以极端谨慎的安全对待。Google Chrome 和 Microsoft Edge 等浏览器要求用户通过权限明确批准，才允许网站通过 MIDI 通信。Safari 和 Firefox 则完全阻止 Web MIDI API，出于对指纹识别和硬件注入漏洞的谨慎考虑。 即时云端备份 ### 厌倦了老式 SysEx 的头痛？ 我们构建了 **knob.monster** 来替代布满灰尘的未签名桌面工具。直接连接你的硬件合成器到浏览器标签页，点击备份，然后在现代、可搜索的云端库中整理你的预设。