Engineering June 23, 2026

Why writing Web MIDI code for 8-bit CPUs from the 1980s is an absolute timing nightmare, and how to safely control data flows on vintage hardware directly from your browser.

Modern browsers run fast. Your system processor operates in gigahertz, handles multi-threaded operations, and loads gigabytes of data in milliseconds.

The microprocessor inside a vintage 1983 Yamaha DX7 is an 8-bit Hitachi 6305 running at a clock speed of 2 MHz, with a tiny 256-byte RAM buffer.

When you try to bridge these two eras using the modern Web MIDI API, you run headfirst into a classic retrocomputing bottleneck: buffer overflow. Send data too fast, and the synthesizer’s CPU hangs, drops packages, or corrupts the internal sound memory completely.

1. The Death of Flow Control (and the $5 Cable Problem)

In the 80s, MIDI physical hardware operated over a current loop running at 31,250 bits per second. While slow, the bandwidth was constant and predictable.

Today, most computer music setups use modern USB-to-MIDI adapters. Modern computers send USB packets at lightning-fast speeds. A cheap, bufferless adapter receives the data at high USB bandwidths, and instantly attempts to serialize and dump it down the MIDI out pin.

Because standard MIDI lacks hardware handshaking lines (no RTS/CTS pins), there's no physical way for the DX7 to tell the browser: "Hey, stop sending data, I'm writing the last preset block to SRAM right now."

To solve this in JavaScript, we have to enforce a custom software flow throttle:

// Chunking and pacing SysEx transmission arrays
async function sendSysExWithPacing(midiOutput, rawSysExBytes) {
    const CHUNK_SIZE = 256; // Limit blocks to prevent buffer floods
    const INTER_CHUNK_DELAY = 60; // Milliseconds to wait between packets

    for (let i = 0; i  setTimeout(resolve, INTER_CHUNK_DELAY));
    }
}

2. Vendor-Specific Hex Parsers

Once you establish a reliable hardware communication link, the next hurdle is decoding the data. Back in the 80s, the MIDI spec defined how notes were triggered, but left the system exclusive (SysEx) parameter format entirely up to manufacturers.

This means every single vintage synthesizer has its own undocumented, proprietary byte structure:

• Yamaha DX7: Spits out exactly 4104 bytes (6-byte header, 4096-byte parameter data, 1 checksum byte, 1 stop byte). The final 10 bytes of each of the 32 voice slots contain ASCII data representing the patch name.
• Roland Juno-106: Does not even support remote dump requests. The synth only speaks when manually prompted: the user has to physically click the 'WRITE' key on the panel to stream its current patch memory.
• Korg M1: Uses a packed 7-bit architecture. Because MIDI status bytes must have the highest bit set to 0, data words are grouped in blocks of 7, with the 8th bits unpacked and appended separately. We had to write custom bit-shifting array decoders in JS just to parse the characters.

3. Browser Security Restrictions

Because Web MIDI allows a website to flash firmware or write raw system-exclusive bytes directly to external physical USB hardware, browsers treat it with extreme security care.

Browsers like Google Chrome and Microsoft Edge require explicit user approval via permissions before allowing websites to communicate over MIDI. Safari and Firefox block the Web MIDI API entirely out of caution regarding fingerprinting and hardware injection vulnerabilities.