Web MIDI Keyboard Latency Tester

What are dead keys on a MIDI keyboard

A dead key is a physical key that fails to send a MIDI Note On message when pressed. On a new keyboard this is almost always a hardware fault: a damaged contact strip, debris under the key, or a broken spring. On older keyboards it can develop over time as the conductive rubber contacts oxidise or wear flat.

The virtual piano on this page lights up every key as MIDI messages arrive. Press each key in turn across the full range. Any key that stays dark when pressed is dead. Because the display maps MIDI note numbers, you can identify the exact note number and report it to a repair technician or manufacturer.

Ghost notes — what they are and how to spot them

A ghost note is the MIDI equivalent of a keyboard's double-tap: a single key press produces two Note On messages for the same pitch in rapid succession. In a DAW this shows up as a stacked double-trigger on a single beat, or a sequencer that records two events where you only intended one. The tester flags any duplicate Note On arriving within 30 ms of the previous one so you can decide whether the behaviour is a hardware fault or just an aggressive playing technique.

What a ghost note is

A ghost note is an unintended duplicate Note On event triggered by a single key press. It appears as a second message for the same note arriving within milliseconds of the first. The symptom in a DAW is an unexpected double-trigger: a note plays twice, or a sequencer records two events stacked on the same beat.

This tester flags any Note On message that arrives within 30 ms of a previous Note On for the same pitch with a red ⚠ GHOST marker in the event log. The 30 ms threshold is a tool setting intended to catch rapid duplicate triggers while avoiding most intentional trills and repeated notes in normal playing.

Why contacts bounce and how to fix it

A bouncing contact strip produces multiple electrical pulses per physical press, which the keyboard reports as repeated Note On messages for the same pitch. Firmware on some keyboards includes a double-trigger prevention setting that filters these rapid duplicates before they reach the MIDI output. For keyboards without that firmware option, a MIDI filter plugin in your DAW can suppress events arriving within a configurable time window. Persistent ghosting on a new keyboard that lacks a firmware fix qualifies as a warranty defect worth reporting to the manufacturer.

USB-to-browser input latency

The lag figure shown in the stats bar and event log is the time between the browser receiving the MIDI message and the moment the key was physically pressed. The figure updates with every Note Off event so you can watch the reading change as you play. More precisely, it is performance.now() − event.timeStamp, where event.timeStamp is the timestamp the browser attaches when the USB MIDI packet arrives at the Web MIDI layer.¹ This tool shows the difference in milliseconds on every row of the event log. Each new key press refreshes the stats bar while the event log keeps every value so you can compare readings across a run.

This measures processing overhead inside the browser. It captures the time spent queuing and dispatching the event on the JavaScript thread but leaves out the full round-trip to audio output. The number can vary by machine, browser, and current workload. Spikes can indicate main-thread contention such as other tabs, heavy page scripts, or a slow garbage-collection pause.² For latency-critical work, close background tabs and use a dedicated browser profile.

A worked reading shows how the pieces add up. Suppose the stats bar reports a lag of 4.2 ms for a key press: that figure is performance.now() minus the event.timeStamp the browser attached when the USB packet arrived, so it reflects OS, driver, and JavaScript dispatch overhead rather than the keyboard's own response. A steady reading in the low single digits on an idle machine is normal. If the same key press later reports 25 ms with several other tabs open, the spike points to main-thread contention rather than a hardware fault, and closing background tabs before retesting usually brings the number back down.

Browser compatibility

The Web MIDI API is supported in Chrome 43+, Edge 79+, Opera 30+, and Firefox 108+; Safari does not implement it.⁵ The same Chromium-based engine also brings support to Chrome for Android and Samsung Internet 4+, and other Android browsers such as the legacy Android browser and UC Browser for Android now support the API as well. Safari has no current support, and you can follow the WebKit tracking bug listed in the compatibility tables to watch for changes. A Web MIDI API polyfill exists for projects that need to target unsupported browsers, though it requires a separate dependency and does not cover every method.

On first use, Chrome will show a permission prompt asking to allow MIDI device access. This prompt is per-origin and persists until you reset it via the lock icon in the address bar.⁶ If you dismissed the prompt accidentally, click the lock icon, find MIDI devices, set it to Allow, and reload the page.

Hot-plugging is fully supported. Connect or disconnect your keyboard at any time and the tool will detect the change automatically without needing a page reload.⁷ Browsers make this possible by firing a statechange event on the MIDIAccess object whenever a port appears or disappears, so the page can react the moment a keyboard is plugged in or unplugged. The Web MIDI specification defines this notification as a MIDIConnectionEvent, which means supported browsers handle live device changes through events rather than by polling the port list over and over.

MIDI velocity, note data, and what the event log shows

Every MIDI Note On message carries three values packed into a status byte and two data bytes, and understanding what each one represents is the key to reading the event log with confidence. The channel selects which instrument or track receives the event, the note number maps to pitch, and the velocity encodes how hard the key was pressed. Together they describe everything the DAW needs to reproduce the performance.

The three values in a Note On message

Every MIDI Note On message carries three values: the channel (1 to 16), the note number (0 to 127), and the velocity (0 to 127). The MIDI Association describes Note On as a channel message with a status byte identifying one of sixteen channels, followed by key number and velocity data.⁸ Channel identifies which instrument or track receives the event. Note number maps to pitch, with middle C being note 60 by the most common convention, though some manufacturers label that pitch C3 while others call it C4.⁹ Velocity encodes how hard the key was pressed; most synthesisers and DAWs translate it to volume, timbre brightness, or both depending on how the patch is programmed.

Velocity response and curves

Velocity response is where significant quality differences between keyboards surface. A cheap controller may quantise velocity into just a few coarse bands rather than distributing responses smoothly across the 1 to 127 range. Pressing the same key repeatedly at different intensities and watching the velocity values in the event log reveals whether the response is linear, stepped, or inconsistent across the range. Some keyboards ship with configurable velocity curves that adjust the relationship between physical press force and the transmitted value. Checking the raw velocity output here gives you a baseline before any curve is applied, so you can judge whether uneven dynamics come from the hardware itself or from a curve setting that needs adjustment in the keyboard software.

Aftertouch

Aftertouch, if your keyboard supports it, is a second pressure value sent after the initial keystroke. Channel aftertouch sends a single value for all held notes simultaneously. Polyphonic aftertouch sends per-note values independently, which requires more sophisticated hardware and rarely appears on entry-level controllers.⁸ Both message types appear in the event log alongside Note On and Note Off entries, letting you confirm that aftertouch hardware responds correctly before you assign it to a modulation target in your DAW or synthesiser patch. Seeing aftertouch messages appear consistently at moderate pressure confirms the mechanism is working; seeing them only at maximum force suggests the sensor threshold needs adjustment in the keyboard's own settings menu.