Tidsreseproblemet i din webbläsare

Tänk dig det här: din JavaScript-applikation körs på en processor som hanterar miljarder operationer per sekund. Yamaha DX7:an på ditt studiobord innehåller en mikroprocessor från 1983 som knappt klarar två miljoner. När du försöker koppla samman dessa två världar med Web MIDI API är det som att be en sportbil att dra en hästvagn – och vagnen har ingen aning om hur den ska få bilen att sakta ner.

Det här är ingen hypotetisk situation. Utvecklare som bygger webbaserade DAW:ar, virtuella instrumentbibliotek eller hårdvarukontrollpaneler stöter allt oftare på den hårda verkligheten: vintage MIDI-hårdvara var helt enkelt inte byggd för att ta emot data i modern hastighet.

Buffer Overflow-verkligheten

MIDI som protokoll designades i början av 1980-talet med en fast överföringshastighet på 31 250 bitar per sekund. Den här långsammare-än-uppringd-hastigheten innebar att hårdvarutillverkare byggde pyttelita buffertar – ofta bara några hundra byte – för att hantera inkommande data. Yamaha DX7 använder till exempel enbart en 256-byte RAM-buffer.

När din webbläsare skickar SysEx-dumpar genom ett USB-till-MIDI-interface bromsar den sig inte enligt MIDI:s historiska hastighet. Istället skjuter den iväg datapaket i USB-bandbredd, vilket överväldigar vintage-hårdvaran som saknar mekanism för att begära paus.

Resultatet? Tysta fel, korrupta patches, eller i värsta fall hänger synthesizern och kräver en omstart. Din tusenlappar DX7 har just blivit ett mycket dyrt pappersviktlager för att din webbapp var för ivrig med att skicka data.

Varför hårdvaruflödeskontroll inte finns i MIDI

Seriella kommunikationsprotokoll innehåller vanligtvis handskakningssignaler – RTS/CTS-stift som låter enheter signalera "sluta skicka" eller "jag är redo". MIDI-kablar har exakt fem stift, och inget av dem fyller den funktionen. Specifikationen inkluderade helt enkelt aldrig ett sätt för mottagande enhet att kommunicera backpressure.

Det skapar en envägsgata där din webbläsare kan skicka data snabbare än synthesizern kan bearbeta den, och synthesizern har ingen röst att säga "vänta". Hela bördan ligger på din programvara att implementera den throttle som hårdvaran borde tillhandahålla.

// Den minimala fungerande pacing-lösningen
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));
}

De här siffrorna fungerar inte för varje enhet. Vissa synthar behöver mer andrum mellan chunkarna, speciellt vid skrivning till EEPROM eller vid patchminnesoperationer. Experiment är oundvikligt – det finns ingen universell standard eftersom hårdvarutillverkarna aldrig föreställde sig att någon skulle skicka SysEx från en webbläsare 2024.

Tillverkarpartitionsproblemet

När du väl löst överföringshastigheten stöter du på ett annat hinder: dataformatkaos. MIDI-specifikationen definierar note events, control changes och program changes, men System Exclusive-meddelanden – bulkdataöverföringar som innehåller patchparametrar – är ett tillverkarfritt för allt.

Yamaha, Roland, Korg och varenda annan synthesizertillverkare hittade på egna bytestrukturer, checksummealgoritmer och voice dump-format. Din webbapplikation behöver veta inte bara vilken enhet den pratar med, utan exakt den bytelayout som enheten förväntar sig.

Yamaha DX7 förväntar sig exakt 4 104 byte för en komplett voice dump. Skicka 4 103, och den avvisar datan. Skicka 4 105, och den kanske accepterar de första 4 104 byten medan den korrupterar whatever som kommer därefter. Roland Juno-106 tar en helt annan approach – den vägrar skicka data om inte en människa fysiskt initierar dumpen från frontpanelen.

Korg:s packade 7-bitars arkitektur lägger till ytterligare ett lager av komplexitet. Eftersom MIDI:s databyte reserverar högbiten för statussignaler komprimerar Korg parameterdatan till 7-bitars ord. Att extrahera de faktiska värdena kräver bitförskjutningsoperationer och byte-uppackning som skulle få vem som helst att uppskatta moderna 8-bitars arkitekturer.

Webbläsarsäkerhet och MIDI API-verkligheten

Web MIDI API är kraftfullt just för att det kan skicka rådata till extern hårdvara. Den kraften gör det farligt. En skadlig webbplats skulle teoretiskt kunna flasha firmware till anslutna enheter eller skicka korrupt SysEx som gör en synthesizern oanvändbar.

Följaktligen behandlar webbläsare MIDI-åtkomst som en privilegierad operation. Chrome och Edge kräver explicit användarbehörighet innan någon MIDI-kommunikation sker. Firefox implementerade aldrig API:t alls, med hänvisning till fingerprinting-problem och potentialen för hårdvarubaserade attacker. Safaris position har skiftat genom åren, men den praktiska verkligheten kvarstår: om du vill att Web MIDI ska fungera tillförlitligt behöver du anta att dina användare kör Chromium-baserade webbläsare.

Den här begränsningen spelar roll för produktplanering. Webbaserade verktyg riktade mot musiker och hårdvaruentusiaster behöver hantera verkligheten att en betydande del av deras publik använder Safari eller Firefox som standard. Progressiv enhancement, där MIDI-funktionerna fungerar för Chrome-användare medan degracefully degraderar för andra, blir essentiellt snarare än valfritt.

Varför det här spelar roll för utvecklare

Vintage synthesizermarknaden är inte nisch. Klassisk hårdvara handlar till premiumpriser på andrahandsmarknaden just för att musiker föredrar ljudet, känslan och arbetsflödet hos enheter från 1980-talet. Att bygga webbverktyg som interagerar med den här utrustningen representerar en verklig utvecklingsmöjlighet – men bara om du förstår begränsningarna.

Varje byte din applikation skickar korsar en bro mellan computing-eror. Besluten du tar om pacing, chunking och formathantering kan betyda skillnaden mellan ett verktyg som musiker älskar och ett som förstör 20 000-kronors synthesizrar. Det är ett ansvar värt att förstå.

Om du bygger MIDI-aktiverade webbapplikationer, börja med den långsammaste fungerande överföringshastigheten, testa med riktig hårdvara tidigt och ofta, och anta aldrig att "det fungerade i min emulator" betyder något för riktiga enheter. Emulatorn har ingen 256-byte buffer som kan overflowa. Dina användares synthar har det.