Problém s rychlostí, který vám rozbije synťák

Představte si, že vaše JavaScriptová aplikace běží na procesoru, který zvládá miliardy operací za sekundu. Yamaha DX7 na vašem stole má procesor z roku 1983, který se tetelí sotva na dvou milionech. Když se je pokusíte propojit přes Web MIDI API, je to jako sundat Formule 1 z okruhu a přimět ji tahat káru sena.

A není to sci-fi. Vývojáři stavějící webové DAW, virtuální nástroje nebo ovládací panely pro hardware narážejí na pořádný problém: vintage MIDI zařízení nikdy nepočítala s tím, že budou dostávat data takovou rychlostí.

Když buffer nestačí

MIDI protokol vznikl začátkem osmdesátých let s pevně danou rychlostí 31 250 bitů za sekundu. Pomalounké to bylo i na tehdejší dobu. Výrobci proto osazovali svá zařízení mini buffery – většinou jen pár stovek bajtů.

Yamaha DX7 má třeba jen 256 bajtů RAM buffer.

Když váš prohlížeč posílá SysEx dumpy přes USB-to-MIDI rozhraní, nezpomalí se na historickou rychlost MIDI. Místo toho pálí pakety v rychlosti USB. A starý hardware na to není připravený – nemá žádný mechanismus, jak říct "počkej, nestíhám".

Výsledek? Tichá selhání, poškozené patche, nebo v horším případě synth prostě zamrzne a musíte ho restartovat. Vaše dvacetitisícová Yamaha se promění v velmi drahou dekoraci, protože vaše webová appka byla příliš nadšená.

Proč MIDI nezná handshaking

Seriová komunikace má obvykle handshaking linky – piny RTS/CTS, které zařízením dovolují signalizovat "zastav" nebo "jsem ready". MIDI kabely mají pět pinů a ani jeden z nich tento účel nesplňuje. Specifikace prostě nikdy nepočítala s tím, že by přijímající zařízení mohlo posílat zpětnou vazbu.

Vzniká tak jednosměrka, kde prohlížeč může posílat data rychleji, než je syntetizér schopný zpracovat. A syntetizér nemá hlas, aby řekl "počkej". Celá zátěž padá na software – musí implementovat throttling, který by měla zajišťovat hardware.

// Minimální řešení pro pacing
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));
}

Tyhle konstanty nebudou sedět každému zařízení. Některé synthy potřebují víc prostoru mezi chunky, obzvlášť při zápisu do EEPROM nebo při operacích s pamětí patchů. Experimentování je nevyhnutelné – univerzální standard neexistuje, protože výrobci nikdy nepočítali s tím, že by někdo v roce 2024 posílal SysEx z webového prohlížeče.

Zmatek ve formátech mezi výrobci

Když vyřešíte rychlost přenosu, narazíte na další problém:格式 chaos. MIDI specifikace definuje notové události, control changes a program changes, ale System Exclusive zprávy – tedy objemnější přenosy s parametry patchů – jsou úplně na divoko.

Yamaha, Roland, Korg a každá další firma si vymyslela vlastní struktury bajtů, checksum algoritmy a formáty voice dumpů. Vaše webová aplikace musí vědět nejen, s jakým zařízením mluví, ale přesně jaký byte layout to které zařízení očekává.

Yamaha DX7 chce přesně 4104 bajtů pro kompletní voice dump. Pošlete 4103 a data odmítne. Pošlete 4105 a může přijmout prvních 4104 bajtů a zbytek corrupted. Roland Juno-106 to řeší jinak – prostě odmítne posílat data, dokud někdo fyzicky nespustí dump z předního panelu.

Korg přidává další vrstvu komplexity s jeho packed 7-bit architekturou. Protože MIDI data bajty rezervují high bit pro status signalizaci, Korg komprimuje parametry do 7-bitových slov. Extrakce skutečných hodnot vyžaduje bit-shifting a byte unpacking, u kterého byste ocenili moderní 8-bitové architektury.

Browser security a realita Web MIDI API

Web MIDI API je silné právě proto, že umí posílat raw data do externího hardware. Tahle síla z něj dělá nebezpečnou věc. Podvrhnutá stránka by mohla teoreticky flashovat firmware připojených zařízení nebo posílat corrupted SysEx, který brickne váš syntetizér.

Prohlížeče proto berou MIDI přístup jako privilegovanou operaci. Chrome a Edge vyžadují explicitní uživatelské povolení. Firefox API nikdy neimplementoval – argumentuje rizikem fingerprintingu a potenciálními hardware útoky. Safari se vyvíjelo, ale praktická realita zůstává: pokud chcete Web MIDI spolehlivě provozovat, počítejte s tím, že vaši uživatelé potřebují Chromium-based prohlížeče.

Pro plánování produktu je to důležité. Webové nástroje mířené na muzikanty a nadšence do hardware musí počítat s tím, že značná část publika používá Safari nebo Firefox. Progressive enhancement, kde MIDI funkce fungují pro Chrome uživatele a graceful degradují pro ostatní, není volitelný bonus – je to nutnost.

Proč by vás to mělo zajímat

Svět vintage syntetizérů rozhodně není nikový. Klasický hardware dosahuje na sekundárním trhu prémiových cen právě proto, že muzikanti preferují zvuk, feel a workflow zařízení z osmdesátek. Stavět webové nástroje, které s tímto gearem komunikují, je reálná vývojářská příležitost – ale jen když rozumíte omezením.

Každý bajt, který vaše aplikace pošle, přechází most mezi výpočetními érou. Rozhodnutí o pacingu, chunkování a zpracování formátů může znamenat rozdíl mezi nástrojem, který muzikanti milují, a takovým, který jim zničí synth za statisíce. To je zodpovědnost, která stojí za pochopení.

Pokud stavíte MIDI-enabled webové aplikace, začněte s nejpomalejší možnou přenosovou rychlostí, testujte na reálném hardware brzy a často, a nikdy nepředpokládejte, že "fungovalo to v emulátoru" znamená něco pro skutečná zařízení. Emulátor nemá 256-bajtový buffer, který může přetéct. Vaši uživatelé synthy ano.