Das Geschwindigkeitsproblem: Wenn der Browser auf Retro-Hardware trifft

Stell dir folgendes vor: Deine JavaScript-App rennt auf einem Prozessor, der Milliarden Rechenoperationen pro Sekunde stemmt. Daneben steht ein Yamaha DX7 aus deinem Studio – ein Synthesizer mit einem Prozessor aus dem Jahr 1983, der es gerade mal auf zwei Millionen schafft. Wenn du jetzt versuchst, diese beiden Welten über die Web MIDI API zusammenzubringen, dann ist das so, als würdest du einen Sportwagen bitten, einen Heuwagen zu ziehen – nur dass der Heuwagen nicht mal die Möglichkeit hat, dem Auto zu sagen, dass es langsamer fahren soll.

Kein hypothetisches Szenario. Entwickler, die browserbasierte DAWs, virtuelle Instrumente oder Hardware-Steuerungen bauen, stoßen zunehmend auf ein echtes Problem: Vintage-MIDI-Hardware wurde niemals für moderne Übertragungsgeschwindigkeiten konzipiert.

Der Buffer-Überlauf: Eine Frage der Größe

MIDI als Protokoll stammt aus den frühen 80ern und arbeitet mit einer festen Übertragungsrate von 31.250 Bit pro Sekunde. Das ist langsamer als ein alter Modem-Anschluss. Die Hardware-Hersteller damals bauten dementsprechend kleine Puffer – oft nur wenige hundert Bytes. Der Yamaha DX7 arbeitet beispielsweise mit einem mageren 256-Byte-RAM-Puffer.

Wenn dein Browser SysEx-Dumps über ein USB-zu-MIDI-Interface schickt, drosselt er sich nicht auf die historische MIDI-Geschwindigkeit. Stattdessen schießt er Datenpakete mit USB-Bandbreite raus und überfordert damit Vintage-Hardware, die keinerlei Mechanismus hat, um „Stopp" zu sagen.

Die Folge? Stille Fehler, corrupted Patches, oder im schlimmsten Fall hängt der Synthesizer und lässt sich nur durch einen Stromzyklus wiederbeleben. Dein 2.000-Euro-DX7 wird zum sehr teuren Papiergewicht – weil deine Web-App zu enthusiastisch beim Datensenden war.

Warum Hardware Flow Control beim MIDI-Standard fehlt

Serielle Kommunikationsprotokolle haben normalerweise Handshake-Leitungen – RTS/CTS-Pins, mit denen Geräte „stopp" oder „ich bin bereit" signalisieren können. MIDI-Kabel haben genau fünf Pins, und keiner davon übernimmt diese Funktion. Die Spezifikation hat schlicht und einfach keine Möglichkeit vorgesehen, wie empfangende Geräte Rückmeldung geben können.

Das Ergebnis ist eine Einbahnstraße. Dein Browser kann Daten schneller senden, als der Synthesizer sie verarbeiten kann – und der Synthesizer hat keine Stimme, um „warte" zu sagen. Die gesamte Verantwortung liegt auf deiner Software, die Drosselung zu implementieren, die eigentliche Hardware gar nicht erst vorsieht.

// Die einfachste praktikable Lösung
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));
}

Diese Zahlen sind nicht für jedes Gerät passend. Manche Synthesizer brauchen mehr Luft zwischen den Datenblöcken – besonders beim Schreiben auf EEPROM oder bei Patch-Speicheroperationen. Ausprobieren ist Pflicht. Es gibt keinen universellen Standard, weil die Hardware-Hersteller schlicht nicht damit rechneten, dass jemand 2024 SysEx aus einem Browser senden würde.

Das Hersteller-Chaos bei den Datenformaten

Hast du das Übertragungsproblem gelöst, taucht direkt die nächste Hürde auf: Datenformat-Chaos. Die MIDI-Spezifikation definiert Note-Events, Control Changes und Program Changes – aber System Exclusive Messages, also die großen Datentransfers mit Patch-Parametern, sind ein herstellerinternes Wildwest-Szenario.

Yamaha, Roland, Korg – jede Synthesizer-Firma hat ihre eigenen Byte-Strukturen, Prüfsummen-Algorithmen und Voice-Dump-Formate erfunden. Deine Web-App muss nicht nur wissen, mit welchem Gerät sie kommuniziert, sondern auch das exakte Byte-Layout kennen, das dieses Gerät erwartet.

Der Yamaha DX7 erwartet exakt 4.104 Bytes für einen kompletten Voice Dump. Schickst du 4.103, lehnt er ab. Schickst du 4.105, akzeptiert er vielleicht die ersten 4.104 Bytes und korruptiert den Rest. Rolands Juno-106 geht wiederum komplett anders vor – er weigert sich, Daten zu senden, es sei denn, ein Mensch initiiert den Dump physisch am Frontpanel.

Korgs gepackte 7-Bit-Architektur legt noch eine Schippe drauf. Weil MIDI-Data-Bytes das höchste Bit für Status-Signaling reservieren, komprimiert Korg Parameterdaten in 7-Bit-Wörter. Die tatsächlichen Werte extrahieren erfordert Bit-Shifting und Byte-Unpacking – Arbeiten, die jedem modernen Entwickler zeigen, wie komfortabel wir es mit 8-Bit-Architekturen haben.

Browser-Sicherheit und die MIDI-API-Realität

Die Web MIDI API ist genau deshalb mächtig, weil sie Rohdaten an externe Hardware senden kann. Diese Macht macht sie gefährlich. Eine bösartige Website könnte theoretisch Firmware auf verbundene Geräte flashen oder korrupte SysEx senden, die einen Synthesizer bricken.

Browser behandeln MIDI-Zugriff deshalb als privilegierte Operation. Chrome und Edge verlangen explizite Benutzerberechtigung, bevor irgendwelche MIDI-Kommunikation stattfindet. Firefox hat die API nie implementiert – aus Datenschutzgründen und wegen potenzieller Hardware-basierter Exploits. Safaris Position hat sich über die Jahre gewandelt, aber die praktische Realität bleibt: Wenn du willst, dass Web MIDI zuverlässig funktioniert, musst du davon ausgehen, dass deine Nutzer Chromium-basierte Browser verwenden.

Das ist wichtig für die Produktplanung. Browserbasierte Tools, die sich an Musiker und Hardware-Enthusiasten richten, müssen damit umgehen, dass ein erheblicher Teil ihres Publikums standardmäßig Safari oder Firefox nutzt. Progressive Enhancement – MIDI-Features für Chrome-Nutzer, graceful Degradation für andere – wird nicht optional, sondern essentiell.

Warum Entwickler das kennen sollten

Der Vintage-Synthesizer-Markt ist alles andere als Nische. Klassische Hardware erzielt auf dem Gebrauchtmarkt Premiumpreise, weil Musiker Klang, Haptik und Workflow von Geräten aus den 80ern bevorzugen. Web-Tools zu entwickeln, die mit dieser Ausrüstung interagieren, ist eine echte Chance – aber nur, wenn du die Einschränkungen verstehst.

Jedes Byte, das deine Anwendung sendet, überquert eine Brücke zwischen Computing-Epochen. Deine Entscheidungen bei Pacing, Chunking und Format-Handling können den Unterschied ausmachen zwischen einem Tool, das Musiker lieben, und einem, das 2.000-Euro-Synthesizer zerstört. Das ist eine Verantwortung, die es wert ist, verstanden zu werden.

Wenn du MIDI-fähige Web-Anwendungen baust, starte mit der langsamsten praktikablen Übertragungsgeschwindigkeit, teste früh und oft mit echter Hardware, und geh niemals davon aus, dass „im Emulator hat es funktioniert" irgendetwas für echte Geräte bedeutet. Der Emulator hat keinen 256-Byte-Puffer, der überlaufen kann. Die Synthesizer deiner Nutzer aber schon.