Problemet med hastighedsmismatch i din browser

Forestil dig følgende: din JavaScript-applikation kører på en processor, der håndterer milliarder af operationer per sekund. Yamaha DX7-synthesizeren på dit studiebord har en mikroprocessor fra 1983, der knap nok klarer to millioner. Når du prøver at forbinde disse to verdne via Web MIDI API, beder du i bund og grund en sportsvogn om at slæbe en hestevogn — og vognen har ingen mulighed for at fortælle bilen, at den skal sætte farten ned.

Dette er ikke et teoretisk scenarie. Udviklere, der bygger browserbaserede DAW'er, virtuelle instrumenter eller kontrolpaneler til hardware, støder i stigende grad på den barske virkelighed: gammel MIDI-hardware var aldrig designet til at modtage data med moderne hastigheder.

Buffer-overløbets realitet

MIDI-protokollen blev udviklet i starten af 1980'erne med en fast overførselshastighed på 31.250 bits per sekund. Denne langsommere-end-opkald-hastighed betød, at hardwareproducenter byggede små buffers — ofte kun få hundrede bytes — til at håndtere indkommende data. Yamaha DX7 opererer eksempelvis med en beskeden 256-byte RAM-buffer.

Når din browser sender SysEx-dumps gennem et USB-til-MIDI-interface, begrænser den sig ikke til MIDI's historiske hastighed. I stedet skyder den pakker afsted med USB-båndbredde, hvilket overvælder vintage hardware, der ikke har nogen mekanisme til at bede om en pause.

Resultatet? Stille fejl, korrupterede patches, eller i værste tilfælde, at synthesizeren fryser og kræver en strømcyklus. Din dyre DX7 er netop blevet en meget kostbar pude, fordi din webapplikation var for ivrig efter at sende data.

Hvorfor hardware flow control ikke findes i MIDI

Serielle kommunikationsprotokoller inkluderer typisk handshaking-linjer — RTS/CTS-ben der lader enheder signalere "stop med at sende" eller "jeg er klar." MIDI-kabler indeholder præcis fem ben, og ingen af dem varetager denne funktion. Specifikationen inkluderede ganske enkelt aldrig en måde for den modtagende enhed at kommunikere backpressure tilbage.

Dette skaber en ensrettet gade, hvor din browser kan sende data hurtigere, end synthesizeren kan bearbejde det, og synthesizeren har ingen stemme til at sige "vent." Byrden falder helt og holdent på din software at implementere den throttling, som hardwaren burde levere.

// Den minimalt fungerende pacing-løsning
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));
}

Disse tal virker ikke for enhver enhed. Nogle synthesizere har brug for mere pusterum mellem chunk, især når der skrives til EEPROM eller udføres patch-hukommelsesoperationer. Eksperimentering er uundgåelig — der findes ingen universel standard, fordi hardwareproducenterne aldrig forestillede sig, at nogen ville sende SysEx fra en webbrowser i 2024.

Producenternes formatkaos

Når du har løst transmissionshastighedsproblemet, støder du på endnu en barriere: dataformat-kaos. MIDI-specifikationen definerer note-begivenheder, control changes og program changes, men System Exclusive-beskeder — de store datatransfer med patch-parametre — er et producent-selvbestaltet kaos.

Yamaha, Roland, Korg og enhver anden synthesizervirksomhed opfandt deres egne byte-strukturer, checksum-algoritmer og voice dump-formater. Din webapplikation skal ikke bare vide, hvilken enhed den kommunikerer med, men det eksakte byte-layout som den pågældende enhed forventer.

Yamaha DX7 forventer præcis 4104 bytes for en komplet voice dump. Send 4103, og den afviser data. Send 4105, og den accepterer måske de første 4104 bytes, mens den korrupterer whatever der kommer bagefter. Roland's Juno-106 tager en helt anden tilgang — den nægter at sende data, medmindre et menneske fysisk igangsætter dumpen fra frontpanelet.

Korg's packed 7-bit arkitektur tilføjer endnu et lag af kompleksitet. Fordi MIDI's databytes reserverer høj-bitten til status-signaling, komprimerer Korg parameterdata til 7-bit ord. At udtrække de faktiske værdier kræver bit-shifting operationer og byte-udpakning, der ville få enhver til at sætte pris på moderne 8-bit arkitekturer.

Browsersikkerhed og MIDI API's virkelighed

Web MIDI API er kraftfuldt netop fordi det kan sende rå data til ekstern hardware. Denne kraft gør det farligt. En ondsindet hjemmeside kunne teoretisk flashe firmware til tilsluttede enheder eller sende korrupteret SysEx, der "bricker" en synthesizer.

Følgelig behandler browsere MIDI-adgang som en privilegeret operation. Chrome og Edge kræver eksplicit bruger-tilladelse, før nogen MIDI-kommunikation finder sted. Firefox har aldrig implementeret API'et overhovedet, angiveligt på grund af fingerprinting-bekymringer og potentialet for hardware-baserede exploits. Safari's position har skiftet gennem årene, men den praktiske virkelighed forbliver: hvis du vil have Web MIDI til at fungere pålideligt, skal du antage, at dine brugere kører Chromium-baserede browsere.

Denne begrænsning betyder noget for produktplanlægning. Browserbaserede værktøjer rettet mod musikere og hardware-entusiaster skal håndtere virkeligheden, at en betydelig del af deres publikum bruger Safari eller Firefox som standard. Progressiv forbedring, hvor MIDI-funktionerne virker for Chrome-brugere, mens de graceful degraderer for andre, bliver essentiel snarere end valgfri.

Hvorfor dette betyder noget for udviklere

Rummet med vintage synthesizere er ikke en niche. Klassisk hardware kommanderer premium-priser på brugtmarkedet netop fordi musikere foretrækker lyden, følelsen og arbejdsgangen fra enheder fra 1980'erne. At bygge webværktøjer, der interagerer med dette udstyr, repræsenterer en reel udviklingsmulighed — men kun hvis du forstår begrænsningerne.

Hver byte din applikation sender krydser en bro mellem computeræraer. De beslutninger du træffer omkring pacing, chunking og formathåndtering kan betyde forskellen mellem et værktøj, som musikere elsker, og et der ødelægger synthesizere til 20.000 kroner. Det er et ansvar værd at forstå.

Hvis du bygger MIDI-aktiverede webapplikationer, så start med den langsomst mulige transmissionshastighed, test med rigtig hardware tidligt og ofte, og antag aldrig, at "det virkede i min emulator" betyder noget som helst for rigtige enheder. Emulatoren har ikke en 256-byte buffer, der kan overløbe. Dine brugeres synthesizere har.