Проблема скорости: браузер против синтезатора

Представьте: ваше веб-приложение работает на процессоре, который выполняет миллиарды операций в секунду. Рядом на столе лежит Yamaha DX7 с процессором 1983 года — тот едва дотягивает до двух миллионов. Когда вы пытаетесь соединить эти два мира через Web MIDI API, получается как попросить спорткар буксировать телегу — вот только телега не умеет просить машину сбавить скорость.

Это не теория. Разработчики, которые делают браузерные DAW, виртуальные инструменты или панели управления оборудованием, постоянно натыкаются на жёсткую реальность: старый MIDI-стандарт просто не рассчитан на современные скорости передачи данных.

Переполнение буфера: из 80-х с любовью

MIDI придумали в начале 80-х с фиксированной скоростью 31 250 бит в секунду. Это медленнее даже древнего модема. Поэтому производители оборудования экономили на всём — буферы делали крошечными, иногда всего несколько сотен байт. Yamaha DX7, например, работает с жалкими 256 байтами оперативной памяти для приёма данных.

Когда браузер отправляет SysEx-дампы через USB-MIDI интерфейс, он не замедляется до исторической скорости MIDI. Вместо этого он выстреливает пакетами на скорости USB, заваливая старое железо данными. А у того нет механизма, чтобы попросить паузу.

Результат? Тихие ошибки, испорченные патчи, а иногда синтезатор просто зависает и требует перезагрузки. Ваш DX7 за тысячу долларов внезапно стал очень дорогим украшением рабочего стола, потому что веб-приложение слишком рьяно отправляло данные.

Почему MIDI не умеет тормозить

В обычной последовательной связи есть сигнальные линии — RTS/CTS, позволяющие устройствам сказать «стоп» или «я готов». MIDI-кабель содержит пять контактов, и ни один из них не используется для этой цели. Стандарт просто не предусмотрел обратную связь.

Получается одностороннее движение: браузер отправляет быстрее, чем синтезатор успевает обрабатывать, а синтезатор не может попросить подождать. Вся ответственность ложится на ваш софт.

// Минимальный рабочий вариант ограничения скорости
async function throttleSysEx(output, data) {
  const PACED_BYTES = 128;
  const DELAY_MS = 80;
  
  for (let offset = 0; offset < data.length; offset += PACED_BYTES) {
    output.send(data.slice(offset, offset + PACED_BYTES));
    await sleep(DELAY_MS);
  }
}

function sleep(ms) {
  return new Promise(resolve => setTimeout(resolve, ms));
}

Эти цифры не универсальны. Некоторым синтезаторам нужны большие паузы между блоками, особенно при записи в EEPROM или операциях с памятью патчей. Эксперименты неизбежны — единого стандарта нет, потому что производители железа не предполагали, что кто-то будет слать SysEx из браузера в 2024 году.

Хаос форматов от производителей

Когда вы решите проблему скорости, появится другая: полная неразбериха с форматами данных. MIDI-стандарт описывает ноты, контроллеры и смену программ, но System Exclusive-сообщения — массивы данных с параметрами патчей — это дикий запад без правил.

Yamaha, Roland, Korg — каждый придумал свою структуру байтов, алгоритмы контрольных сумм и форматы дампов. Вашему веб-приложению нужно знать не только устройство, но и точный порядок байтов, который оно ожидает.

Yamaha DX7 ждёт ровно 4104 байта для полного дампа голоса. Отправьте 4103 — откажет. Отправьте 4105 — может принять первые 4104 и испортить остаток. Roland Juno-106 вообще отказывается принимать данные, пока человек физически не запустит дамп с передней панели.

Korg добавляет ещё один слой сложности. MIDI резервирует старший бит для статуса, поэтому Korg сжимает данные в 7-битные слова. Извлечение реальных значений требует побитовых операций и распаковки — удовольствие ниже среднего.

Безопасность и реальность Web MIDI API

Web MIDI API мощный именно потому, что умеет отправлять сырые данные на внешнее железо. Эта мощь делает его опасным. Вредоносный сайт теоретически может прошить firmware на устройстве или отправить испорченный SysEx, который положит синтезатор.

Поэтому браузеры относятся к MIDI-доступу как к привилегированной операции. Chrome и Edge требуют явного разрешения пользователя. Firefox не реализовал API вообще — из-за проблем с fingerprinting и потенциальными атаками на оборудование. Safari менял позицию, но на практике: для стабильной работы Web MIDI нужны Chromium-браузеры.

Это важно для планирования продуктов. Браузерные инструменты для музыкантов должны учитывать, что часть аудитории сидит на Safari или Firefox. Progressive enhancement, когда MIDI работает для пользователей Chrome, а для остальных gracefully деградирует — не роскошь, а необходимость.

Почему это важно

Рынок винтажных синтезаторов — не ниша. Старое железо стоит дорого на вторичке именно потому, что музыканты предпочитают звук, ощущения и рабочий процесс устройств из 80-х. Веб-инструменты, взаимодействующие с таким оборудованием — реальная возможность, но только если понимать ограничения.

Каждый байт из вашего приложения пересекает мост между эпохами вычислений. Решения о темпировании, разбиении на блоки и обработке форматов решают: получится инструмент, который музыканты полюбят, или устройство, которое уничтожит двухтысячный синтезатор. Это ответственность, которую стоит осознать.

Если делаете MIDI-приложение для браузера — начинайте с минимально возможной скорости отправки, тестируйте на реальном железе как можно раньше и часто, и никогда не думайте, что «заработало в эмуляторе» значит хоть что-то для реальных устройств. В эмуляторе нет 256-байтного буфера, который может переполниться. А в синтезаторе пользователя — есть.