Web MIDI Keyboard Latency Tester

For any USB MIDI device Chrome recognizes, a browser MIDI device tester shows every message it sends in real time. Connect your MIDI controller, click "Enable MIDI", select the device from the dropdown, and watch the event log capture notes, CC values, pitch bend, and aftertouch. No DAW installation or virtual MIDI bus is needed, and class-compliant devices usually use the operating system's MIDI driver without a manufacturer driver package.¹² The Web MIDI API gives Chrome direct access to the raw MIDI stream.

Browser-based testing differs from DAW testing in one important way: the browser sees the raw hardware output before any DAW plugin processes it. A controller that appears to work in a DAW but behaves unexpectedly may have its CC output remapped by a DAW input filter. Testing here isolates the hardware itself. Consequently, comparing what appears in the browser event log against what your DAW receives is the fastest way to determine whether an issue lives in the hardware or the software.

What the MIDI device tester checks

The tester captures common MIDI message types the device sends: Note On and Note Off with velocity and channel, Control Change (CC) with number and value, pitch bend (0xE0) with 14-bit value, and channel aftertouch (0xD0). SysEx messages appear if the device sends them, though their content depends on manufacturer-specific encoding.³ Each message arrives in the event log with a timestamp and a Lag value showing browser processing overhead.

Reading the message type column

Start with the message type before judging the value. Note On and Note Off confirm key and pad routing, CC confirms knobs and faders, and 0xE0 confirms pitch bend output. That sequence keeps the first diagnosis focused on what the device actually transmits.

Because the tester captures all MIDI channels simultaneously, multi-channel devices, such as drum pads that route kick and snare to different channels, show all channels in a single log without requiring any per-channel filter setup.³

How to select and test a device

After granting MIDI access, the MIDI input dropdown lists every device the operating system recognizes. Select your device and it immediately starts receiving.¹⁴ For keyboards, press every key across the full range and watch the virtual piano for dark keys. For controllers with knobs or faders, rotate and slide each one and verify that the correct CC number appears in the log.

Testing one device at a time

You can connect and test multiple devices in the same session by switching the dropdown selection. If you expect a device to appear but it does not, disconnect and reconnect it, then refresh the dropdown. The event log persists between device switches, so you can compare the output of two keyboards side by side without losing the first device's data. Click "Clear Log" before switching to start a fresh session for the new device.

Interpreting results compared to a DAW

When a controller works in the browser tester but not in your DAW, the issue is almost always DAW configuration rather than hardware. Check that the MIDI input is enabled in the DAW's device preferences, that the MIDI channel matches what the controller sends, and that no input filter is blocking the CC number the controller uses. In Live, for example, every MIDI port carries a Track toggle that has to be enabled before note and CC messages can reach a MIDI track at all, and each track's Input Type chooser has to point at that specific port or at All Ins.⁵

Conversely, if the tester shows no events at all from the device, the problem is at the OS or browser layer rather than the DAW. Verify the OS recognizes the device (Windows Game Controllers / Device Manager, macOS Audio MIDI Setup, Linux /dev/input or /dev/snd), then troubleshoot from the OS level upward before returning to the browser.

Managing multi-device sessions and log clarity

Testing multiple devices in one session requires a disciplined event log workflow so you can compare two MIDI controllers at once without confusing events from different devices. Click "Clear Log" before switching the MIDI input dropdown to a new device. Events from the previous device persist until you clear them, and a log containing events from two different devices is harder to interpret than a clean log for each one. Note the device name visible in the dropdown at test time before clearing, so your screenshot identifies which hardware produced those events.

For controllers with many simultaneous CC outputs, such as a keyboard with 16 encoders and 9 faders all transmitting on different CC numbers, test one section of controls at a time and clear the log between sections. Testing all controls simultaneously produces a dense log where events overlap in timestamp order, making it difficult to identify which CC number belongs to which physical control.

Using the dropdown refresh during hot-plug testing

Some devices require a refresh of the MIDI input dropdown after reconnecting. Click the refresh icon to update the device list without reloading the page. The browser already tracks connection changes on its own, since the Web MIDI API delivers a MIDIConnectionEvent whenever a port becomes available or unavailable.⁶ The event log persists during a refresh. Leave the log running through a reconnection to capture any initialization CC messages the keyboard sends on connect; these appear immediately as the device registers and reveal factory default CC states.

Run this test when you need to verify a new controller before setting up a DAW, when a DAW session reports missing MIDI events, or when you want to confirm a device is transmitting the correct MIDI messages and channels before building a new project around it.

A browser MIDI keyboard test works best before you open a DAW, because it removes software routing from the first diagnosis. Connect your keyboard via USB, click "Enable MIDI", and every key you press lights up on a virtual piano. Any key that stays dark on a firm press is not transmitting MIDI. The Web MIDI API in Chrome, Edge, and Opera gives you direct access to the raw MIDI stream from your keyboard without installing a DAW or any device software.¹

Beyond dead keys, browser-based testing catches two other common issues before they disrupt a recording session. Ghost notes appear as duplicate Note On events in the event log shortly after the first, a sign of contact bounce or a sensor that fires twice per press. USB-to-browser latency shows in the Lag column for every event, with typical values of 0.5–3 ms on an idle machine and consistent spikes pointing to main-thread contention rather than hardware problems.

What the browser MIDI test diagnoses

Dead keys, ghost notes, and velocity inconsistency are the three most common hardware issues visible in browser-based MIDI testing. A dead key sends no Note On at any pressure. The virtual piano stays dark and the event log shows no entry. A ghost note sends two Note On events for a single physical press in quick succession, flagged as ⚠ GHOST in the log. Velocity inconsistency shows as a key logging significantly lower velocity than adjacent keys at the same physical pressure, indicating early contact strip wear before full failure.²

Reading the raw signal before DAW processing

Because testing happens in the browser without a DAW in the signal path, every event the log captures is raw hardware output. Consequently, you see exactly what the keyboard sends, not what a DAW plugin or virtual instrument receives after its own processing. This distinction matters because a DAW can apply velocity curves, arpeggiation, or channel remapping that alter the signal before it reaches the virtual instrument.

How to run the test step by step

Connect your keyboard via USB before opening this page. After granting MIDI access in Chrome's permission dialogue, your keyboard appears in the MIDI input dropdown. Select it and press every key across the full range from the lowest note to the highest. Watch the virtual piano for dark keys and the event log for ⚠ GHOST markers.

Running a controlled key sweep

Press one key at a time from lowest to highest, then repeat from highest to lowest. A repeatable dark key in both directions is more useful evidence than a single missed soft press.

For velocity testing, press each key at three different intensities (soft, medium, and hard) and note the velocity values in the event log. A healthy key should produce values across the full 1–127 range proportional to your playing force.³ Building on this, use the "Clear Log" button between key sections so the log does not overflow during a full 88-key sweep.⁴

Next steps after identifying issues

A dead key on a keyboard still under warranty is grounds for a manufacturer repair or replacement. Screenshot the event log showing no Note On for the specific note number and include it with your warranty claim. For keyboards out of warranty, a repair shop can replace the contact strip section covering the dead key for a modest cost in most cases.

Ghost notes that appear on specific keys often resolve with firmware updates. Check the manufacturer website for recent firmware before sending the keyboard for repair. Furthermore, ghost notes on multiple adjacent keys simultaneously suggest a contact strip section issue rather than an individual key fault. Persistent USB latency spikes above 10 ms point to a driver or USB bandwidth issue, not a keyboard hardware fault. Ableton's MIDI fact sheet explains the mechanism: interface drivers attach a timestamp to each incoming MIDI event, and a DAW adds extra delay derived from the audio hardware buffer size, so the delays a DAW reports are partly software bookkeeping rather than a measure of the keyboard itself.⁵

Documenting test results for warranty claims

Documenting the test before closing the browser takes less than one minute and creates a record you can reference for warranty claims, repair conversations, or future comparisons. Take a screenshot with the event log visible and the MIDI device name showing in the dropdown above the log. Include any ghost note markers or the absence of Note On entries for specific note numbers. Every timestamp in that log comes from the browser's MIDIMessageEvent, which the Web MIDI API delivers only in a secure context and only after you grant explicit permission, so a logged event proves the whole chain from key contact to page script is working.⁶ This gives a repair technician or customer support team the note number, the channel, and a timestamp without requiring them to reproduce the issue themselves.

For warranty purposes, a screenshot of an empty event log entry for a specific note is more persuasive than a verbal description. Most manufacturers accept screenshots directly through their support portal. Point to MIDI note 60 (middle C) showing no events across ten presses with the keyboard connected and the MIDI permission granted. The note number identifies which physical key is affected without requiring the manufacturer to reproduce the issue.

Comparing test results over time

Running the test periodically on the same keyboard creates a longitudinal record. A key that produced velocity values between 20 and 120 in January and narrows to 40 to 110 in June is showing early contact strip wear. Catching this compression early means you can plan a repair before the key fails mid-session. Save screenshots with the date in the filename to make comparisons easy.

Run this test when you suspect a key is not responding, when you hear unexpected double-triggers in your DAW, or sweep a MIDI keyboard before returning a recently purchased unit to confirm it is fully functional.

A MIDI CC test confirms that knobs, faders, encoders, and pedals send the control data your DAW expects. MIDI Control Change messages use status bytes 0xB0 through 0xBF, with the low nibble indicating the MIDI channel, and carry controller values between 0 and 127.¹ Knobs, faders, encoders, and sustain pedals all generate CC messages.² Testing CC output directly in Chrome confirms that each control element sends the correct CC number on the correct MIDI channel without remapping or dropout, which is critical verification before assigning those controls in a DAW or synthesizer.

The event log shows every CC message as it arrives: the CC number, the value, and the MIDI channel. Rotate a knob slowly from minimum to maximum and the log should show a mostly increasing sequence of CC values for the assigned CC number, allowing for small direction changes or bounce from the physical control. Any gap in the sequence indicates a dead spot on the control's resistive track. Any wrong CC number indicates the control was remapped from its expected default, either in firmware or in companion software.

What MIDI CC messages are

MIDI defines 128 CC numbers (0–127), each assigned to a controller function or channel mode message.³ Common CC assignments include CC 1 for modulation, CC 7 for channel volume, CC 10 for pan, CC 11 for expression, and CC 64 for damper pedal or sustain.⁴ Controllers 70 and above include sound controllers, general-purpose controllers, portamento control, undefined positions, and channel mode messages, so hardware manufacturers often use the upper range for device-specific knob and slider assignments.¹

Matching the CC number to the control

The CC number identifies which control moved, while the value identifies where that control is positioned. A knob can be healthy even when its CC number differs from your DAW preset, because remapping can change the number without changing the physical control.

CC messages differ from Note On messages in that they carry a controller value rather than key velocity.² They represent the position or state of a physical control rather than the timing of a strike. Consequently, holding a knob in position does not generate ongoing CC messages; Control Change messages are sent when a controller value changes.³ Sustain pedals are expected to cross the CC 64 threshold on press and return below it on release; many pedals send 127 on press and 0 on release, but the MIDI threshold is the compatibility requirement.⁴

How to test each CC control

For rotary knobs and faders, move each control slowly from its minimum position to its maximum position and watch the event log. A healthy control sends a smooth sequence of CC values from 0 to 127 (or 127 to 0, depending on direction) with no gaps. Identify the CC number assigned to each control by reading the number column in the log. If the displayed CC number differs from the expected assignment, the control has been remapped.

Recording a clean CC sweep

Move one control at a time and clear the log between sections when the controller has many knobs or faders. A clean sweep makes dead spots, jumps, and wrong CC numbers easier to see than a dense log containing every control at once.

For sustain pedals and latching buttons, press and hold, then release. The log should cross the CC 64 threshold on press and return below it on release; many pedals and buttons send 127 when pressed and 0 when released, but the exact values depend on the controller.⁵ Confirm each button's on/off behavior by pressing and releasing while watching the log.

Common CC issues and what they indicate

A fader or knob that produces gaps in the CC value sequence has a dead spot on its resistive track, the physical wear point where debris or carbon track erosion prevents the wiper from reading certain positions. Move the control slowly through the dead spot range to characterize its extent. A narrow jump is often cleanable; a wide jump typically requires element replacement.

An encoder that sends burst CC events, rapid bursts of the same CC number within milliseconds of a single rotation, has a mechanical debounce issue. Rotate more slowly to confirm whether clean single events appear at lower rotation speeds. An encoder that consistently sends the wrong CC number has been remapped either in keyboard firmware settings or in companion software.

14-bit CC and NRPN for high-resolution controllers

Standard 7-bit CC provides 128 steps across a control's range, which can produce audible stepping on high-resolution parameters like filter cutoff or pitch fine-tune.⁵ Some keyboard controllers support 14-bit CC to extend this by pairing most-significant byte controllers 0 to 31 with least-significant byte controllers 32 to 63.⁶ A mod wheel on a keyboard that supports 14-bit CC sends CC 1 (MSB) and CC 33 (LSB) as paired events; together they encode a higher-resolution value than ordinary 7-bit CC.

The event log shows both CC messages when they arrive. A 14-bit mod wheel produces two consecutive entries: CC 1 with a coarse value and CC 33 with a fine value. Not all synthesizers process both bytes; many treat only the MSB and ignore the LSB, effectively degrading the resolution back to 7 bits. Confirm your synthesizer supports 14-bit CC before relying on the extended resolution in a mix.

NRPN messages for synthesizer parameter control

Non-Registered Parameter Number (NRPN) messages encode synthesizer-specific parameters beyond the standard 128 CC numbers. The official CC table identifies CC 98 and CC 99 as NRPN LSB and MSB, and CC 6 and CC 38 as data entry MSB and LSB.⁶ If your controller sends NRPN for certain controls, confirm the message sequence appears in the correct order whenever you move those controls.

Run this test when a knob or fader does not respond correctly in your DAW, when you want to read every knob CC number before building a DAW mapping, or when troubleshooting why a sustain pedal or expression pedal behaves unexpectedly.

The Lag column in this tester estimates USB-to-browser MIDI latency, the time between a MIDI packet arriving at the Web MIDI layer and the current browser timestamp.¹ It is calculated as performance.now() − event.timeStamp.² On an idle machine with a quality USB cable, expect low single-digit millisecond values; consistently high values usually point to browser main-thread contention rather than keyboard hardware problems.

This measurement is not the same as the full round-trip latency from key press to audio output. It captures only the browser processing overhead above the USB hardware layer, specifically the time spent queuing and dispatching the MIDI event on the JavaScript thread. What the Lag column shows is whether the browser's main thread is free to process incoming events promptly.

What USB-to-browser latency measures

USB full-speed MIDI polling occurs at the hardware level every 1 ms, meaning the USB subsystem checks for new MIDI data from the keyboard at a minimum 1 ms interval.³ The kernel MIDI driver picks up the packet and passes it to the Web MIDI API. The API timestamps the event using a high-resolution clock (event.timeStamp) at the moment the packet enters the browser MIDI subsystem.¹

Separating MIDI lag from audio latency

The Lag value does not include audio driver buffering or software instrument processing. It only shows how quickly the browser dispatches the MIDI event after the packet arrives. That makes it useful for finding browser contention before you blame the keyboard.

From that timestamp to the moment your JavaScript handler runs is the Lag. A browser tab with heavy background work, such as other scripts running, garbage collection pauses, or rendering pipelines flushing, delays the dispatch and increases the Lag value. Consequently, this measurement reflects browser health rather than keyboard hardware quality.

How to get accurate latency readings

For the most meaningful results, test on an otherwise idle machine. Close unnecessary tabs, pause any media playback, disable browser extensions (especially those that inject JavaScript into pages), and disconnect other USB devices that generate frequent interrupts. Run the test for at least 30 seconds before evaluating the Lag statistics.

Creating a stable latency baseline

Press keys at regular intervals, roughly one per second, rather than holding chords. Each key press generates a single Note On event with its own Lag measurement. Building on this, compare Lag values before and after closing other tabs to isolate whether tab contention or extension scripts are responsible for elevated readings. A consistent lag reading across 30 or more events gives you a reliable baseline to compare against after making system changes.

Interpreting the latency values

Values of 0.5–3 ms indicate a healthy browser processing environment. Values of 3–10 ms suggest moderate main-thread contention. This is not necessarily a problem for most MIDI applications but is worth investigating if you notice audio artifacts. Values consistently above 10 ms indicate significant contention: close other tabs, disable extensions, or switch to a less-loaded browser profile.

For latency-critical work such as live performance with software instruments or real-time synthesis, the browser-to-audio-output latency is the relevant number, not the USB-to-browser lag shown here. Use your DAW's audio latency measurement instead for performance optimization. This test is most useful for ruling out USB connectivity issues before assuming an audio driver is the bottleneck.

Interpreting latency baselines by connection type

Latency baselines differ significantly depending on connection type, machine load, and browser configuration, which is why you should measure USB against Bluetooth MIDI lag on the same machine for a fair comparison. On a direct USB 2.0 or USB 3.0 connection with Chrome as the only active tab and no browser extensions, the typical Lag range is low single-digit milliseconds. On a USB hub with other active USB devices, the range can expand because the bus has to arbitrate between devices. On Bluetooth MIDI, the Lag column value itself may stay low because it measures only browser processing overhead, but the total latency from key press to browser dispatch includes the negotiated Bluetooth connection interval, which starts at 7.5 ms and can be higher depending on the connection.⁴

Recording these baselines on your specific machine gives you a reference point for troubleshooting future sessions. A session where Lag values climb well above the normal baseline on a direct USB connection indicates browser main-thread contention. Close background tabs, disable extensions, and check Activity Monitor or Task Manager for processes consuming CPU.

GPU rendering and browser Lag spikes

Chrome's GPU compositing pipeline can produce Lag spikes that correlate with screen rendering rather than MIDI processing. If you see isolated spikes on an otherwise idle machine, move the browser tab to a position where no other application window overlaps it. Browser rendering work competes for the same main thread that dispatches JavaScript MIDI events, so reducing visual work can reduce event dispatch jitter.⁵

Run this test when your browser MIDI processing feels sluggish, when you want to verify USB connectivity before a recording session, or when troubleshooting why your DAW reports higher MIDI input latency than expected on a machine that otherwise performs well.

A MIDI velocity test shows whether each key still produces a useful dynamic range. For sounding notes, MIDI velocity is commonly displayed from 1 to 127; Note On velocity 0 is commonly treated as a Note Off event.¹ Connect your keyboard, press keys at different intensities, and compare the velocity values in the event log. A healthy key produces a wide range proportional to your playing force, while a worn key produces consistently compressed or fixed values regardless of how hard you press.

Most keyboards use a two-contact system to measure velocity. The time between the first contact (key begins traveling) and the second contact (key reaches the bottom) determines the velocity value.² A shorter interval means a faster press, which maps to a higher velocity. When the contact strip wears, either contact can register late, early, or not at all. The timing measurement becomes unreliable and velocity output compresses toward a fixed range.

How velocity works at the hardware level

Under each key is a rubber dome with two conductive strips at different heights. When you press the key, the first strip contacts the PCB and starts a timer. When the key reaches full travel, the second strip contacts and stops the timer. The keyboard firmware converts this timing into a 7-bit MIDI velocity value.¹

Reading velocity as timing, not force

Velocity is the time between two contacts, not a direct force sensor reading. A key can feel physically strong but still send low velocity if the second contact closes late. That distinction matters when you compare one key against its neighbors.

This two-contact design means velocity is a time measurement, not a pressure measurement.² Pressing gently means the key travels slowly, producing a long time between the two contacts, which maps to a low velocity. Pressing hard means fast travel, a short time, and high velocity. Consequently, any hardware failure that disrupts either contact point produces incorrect velocity output.

How to test velocity sensitivity

Press each key at three distinct intensities: as gently as possible, at medium force, and at maximum force. For each key, the logged velocity values should span a wide range from soft to loud. Any key where the values cluster in a narrow range regardless of press intensity has a velocity problem.

Comparing velocity ranges instead of single hits

For a systematic sweep, play a scale from the lowest note to the highest, pressing at consistent medium pressure across all keys. Keys that produce significantly lower velocity than adjacent keys at the same force have worn contact strips that are failing to register the second contact correctly. Building on this, compare the minimum and maximum velocity achievable on each key. A key where you cannot get below the same moderate velocity even with a feather touch is sending compressed velocity output.

What compressed or fixed velocity indicates

A key that sends maximum velocity for almost every press often has contact strips where the two contacts are close together, so the timing interval is always nearly zero. This can indicate advanced wear, and the strip may fail completely soon. An iFixit teardown of a Korg MicroKORG shows why: the rubber contact strips come out as three removable sections, and their guide notes that strips in bad shape need replacing rather than cleaning.³ A key that always sends the same moderate velocity can also come from fixed-velocity mode or a sensor/configuration issue, so check the keyboard settings before replacing hardware.

Early-stage wear shows as a compressed range: a key that can produce some dynamic variation but not the full soft-to-loud span. This is catchable before the key goes dead. Screenshot the velocity distribution and monitor it over time. A range that continues to compress across weeks of use confirms the contact strip is degrading rather than just showing manufacturing variation.

Disabling keyboard velocity curves before testing

Before drawing conclusions from velocity readings, confirm that the keyboard's internal velocity curve is set to neutral or linear. Many controllers apply a default velocity curve that shifts how hard a press must be to reach low or high values. When the curve is soft, high velocities become harder to reach; when hard, low velocities become harder to reach. Either curve shifts what the event log shows away from the raw hardware timing measurement, so disable a velocity curve before testing in the keyboard settings to see the unprocessed output. Live's Velocity MIDI effect shows how that remapping works in practice: its curve grid maps incoming velocity values from 1 to 127 onto an outgoing range, its Gate mode removes values outside the range you set, and its Fixed mode sends one identical value regardless of the incoming velocity.⁴

Check the keyboard companion software or OSD menu for velocity curve settings. Novation documents Low, Normal, High, and Fixed velocity options, and its Fixed mode outputs the same MIDI velocity regardless of how hard or soft a key is pressed.⁵ Set the curve to Linear, Default, or the equivalent neutral setting, confirm the change was saved to the keyboard firmware, and retest. Compare the velocity range to your pre-change reading.

Identifying curve-induced compression versus hardware wear

A key that produces a compressed range with a soft curve but a wider range when set to Linear is responding correctly; the curve was masking its full range. A key that produces the same compressed range with both a soft curve and a linear curve applied is showing genuine hardware compression. Monitor that key over time. Hardware compression that persists with a linear curve confirms contact strip degradation rather than a curve misconfiguration.

Run this test when your playing dynamics feel unresponsive in a DAW, when soft passages sound too loud or loud passages feel compressed, or when you want to catch early contact strip wear before a key stops responding entirely.