Pimp My IDE / garage dispatchBack to the garage
13 Oct 2026 / keyboard input / interface craft

A keyboard control needs an owner.

The fun part is the chord. The hard part is focus, physical position, held-key state, release, and silence when the user is typing somewhere else.

Focus firstKey down plus key upSound stays opt in

The keyboard can be an instrument.

Guitoro maps one side of a computer keyboard to chords and the other side to strums, picking, mutes, and song controls. It also accepts touch and mouse input. Its public guide says the keyboard map follows physical positions on a United States QWERTY layout.[1]

That turns a familiar input device into a two-handed control surface. It also exposes every choice a keyboard-heavy web interface has to make. Does the app care about the character printed on a key or its physical position? What happens when two keys are held? Who owns the key when a text field has focus? What releases a visual state if the window loses focus?

A shortcut is a moment. An instrument is a state machine.

Choose position or meaning.

KeyboardEvent.code names a physical key position. MDN uses game controls as its main example because the same physical cluster can stay useful across keyboard layouts. The printed character can differ. A position reported as KeyQ on a QWERTY keyboard may carry another label on Dvorak or AZERTY.[2]

KeyboardEvent.key reports the key value after the keyboard layout and modifier state are applied. Use it when the character matters. Use code when the physical arrangement matters. If you choose physical positions, show the actual control labels and document the layout assumption. Do not tell an AZERTY user to press a printed Q when the app is listening for the physical position.

Track press and release.

A one-shot shortcut can act on keydown. A held control needs both keydown and keyup. MDN recommends that game-like controls start motion on press and stop on release instead of depending on operating-system key repeat. That also permits simultaneous controls.[2]

Keep a set of active keys. Ignore repeated keydown events for keys already in the set. Remove each key on keyup. Clear the set on window blur so a released key does not remain visually stuck after the tab loses focus.

Focus is the first interlock.

Global listeners make demos feel immediate, but they can steal letters from forms, editor surfaces, browser commands, and assistive input. Give the control a focusable housing. Act only while that housing owns focus. Leave Tab, Escape, system shortcuts, and text fields alone.

Mouse and touch users still need visible controls that perform the same actions. Native buttons supply focus, activation, and labels without recreating those contracts. The soundcheck below uses four buttons and an optional keyboard layer. The visual state works when Web Audio is unavailable.

Sound starts after consent.

MDN summarizes browser autoplay policy as creating or resuming an audio context inside a user gesture. It also recommends clear play, stop, volume, and mute controls for pages that make sound.[3]

The bench therefore starts silent. The arm button creates or resumes its audio context. Disarming it stops sound without disabling the visible pads. No key press outside the focused playfield produces a note.

Interactive makeover / shortcut list replaced

Run the key soundcheck.

This input rig combines a native mode selector, explicit audio arm, focus boundary, held-key display, clickable pads, and event log. It tests this page's small mapping. It does not measure hardware rollover or prove another application handles input correctly.

Own focusResolve mapTrack stateRelease cleanly

Input map

Choose what the four pads mean. Then arm sound if you want it. The control remains usable with sound off.

Mapping mode

Sound is off. Visual input is ready.

Why this is better: a shortcut table lists names. This rig exposes focus ownership, map choice, simultaneous state, release behavior, and the silent fallback.

Four-channel key deck

Focus this housing, then hold A, S, D, or F. Release the key to release its pad. You can also click or tap each button.

Input housing / focus required0 held
STATE=SILENT_READY FOCUS=PRESS TAB TO ENTER PLAYFIELD MAP=PHYSICAL_POSITION HELD=NONE LAST_EVENT=NONE
Sources read / 13 Oct 2026

Source log

Open the evidence boundary
  1. Guitoro, virtual guitar and public guide, read October 13, 2026. The page documents keyboard, touch, and mouse control; physical QWERTY positions; separate chord and strum hands; held chords; songs; local recordings; and user-started sound. These are publisher descriptions. We used the public page and did not inspect private implementation code.
  2. MDN, "KeyboardEvent: code property", read October 13, 2026. It separates physical key position from generated characters and recommends keydown plus keyup state for game-like simultaneous controls.
  3. MDN, "Web Audio API best practices", read October 13, 2026. It covers user-gesture startup, suspended audio contexts, explicit user controls, and accessible labels.
  4. Hacker News item 50077020, resolved through the Hacker News API and read October 13, 2026. It maps the current discussion to the exact Guitoro URL. Product claims come from Guitoro's page.

Evidence boundary: the soundcheck is an original browser-local teaching demo. It exercises focus-scoped keyboard handling, two map modes, repeat suppression, held-key state, blur cleanup, native buttons, and optional Web Audio tones. It does not test keyboard hardware rollover, latency, sample playback, international keyboard coverage, screen-reader command conflicts, or Guitoro's implementation.