Omunikorudo, Web Edition

In plain terms: a browser version of the Suzuki Omnichord, a Japanese instrument where you press a chord button with one hand and strum a touch-strip with the other.

Status

live

Demo

open

Stack

Web Audio

Hard part

faithful chord grammar

why

I bought a MacBook Pro and a Suzuki Omnichord in 2025, and quickly noticed I was reaching for the Omnichord instead of my guitar. Chord shapes that take work on a fretboard are one button on the Omnichord, then a strum. The browser version started as flattery: a few good replicas already exist online, and this one is my redesign for the computer screen. I type faster than I play any instrument, so a chord-button mapped to a keyboard key is faster than a chord-button mapped to a hand.

That’s the cognitive trap, too. There’s a 1935 psychology experiment called the Stroop test where you’re shown the word green printed in red ink and asked to name the ink color, not read the word, and the reading instinct interferes with the seeing instinct. A keyboard key playing a chord is more efficient than a finger on a fret, technically, and cognitively it’s that red card with the word green on it. You have to read the chord, not the keystroke. The gap between those two readings is where the instrument lives.

Why rebuild the Omnichord in the browser? The OM-108 has a row-combination grammar no other instrument copies: pressing two keys in the right rows produces a chord no keyboard player would have figured out alone. The instrument’s appeal is the grammar, and the grammar is what every browser instrument I’d tried had quietly skipped. The wedge for Omunikorudo is authenticity over abstraction: the 108-chord grammar is the product, not a piano roll dressed up in a “lo-fi” preset.

what I built

• Three staggered rows of keycaps (MAJ, MIN, 7TH), laid out in circle-of-fifths order and mapped one-to-one to physical-keyboard rows so a real keyboardist can reach them by feel.
• Touch/mouse strumplate: vertical motion becomes the strum, with arpeggio behavior that scales with gesture speed.
• Twin amber-LCD displays for chord and octave; HOLD latching to free both hands for songwriting.
• Lo-fi DSP rack (detune, bitcrush, vinyl crackle, tape wobble, convolution reverb) tuned to be musically usable, not gimmicky.
• Hint overlay that teaches the row-combination grammar.
• Hardware-style chassis: cream OM-108 body, brass strumplate, ivory keycaps, navy silk-screen print, brass screws, rubber feet.

There is no “Start Audio” button: the audio engine initializes on first input. That’s not a feature, it’s onboarding.

the grammar

The OM-108’s keyboard is small (three rows of chord buttons spread across the chromatic roots, one button per chord type per root), and the obvious read is that’s a fixed-vocabulary chord pad, fine, modest range, basic instrument. The actual range is bigger, because the instrument is grammatical. Pressing two buttons together isn’t a chord-stack; it’s a rule.

Three rules:

• Single press: one button, one chord.
• Same-column stack: two rows in the same column extend the chord at that root, a color tone added to a single harmonic center.
• Offset column: two rows offset by one or more columns produce something altered or suspended. Same root, redirected, often into a chord that no row alone can name. Several of these have no single-button equivalent on a keyboard at all.

The column order is the second half of the grammar. The caps don’t run chromatically; they run the circle of fifths, so left-and-right neighbors are always one harmonic step away from the root. That choice means the offset rule isn’t arbitrary: a one-column shift between MAJ and 7TH lands you on a chord that already wants to resolve to the root you started on, which is why the result is a sus4 and not noise. Chromatic order would have given a different instrument, and a worse one.

The truth table sits behind all of it. Every (row × column × row × column) combination resolves to exactly one chord, authored by hand in a spreadsheet before any component was written. Once the table existed, what should this combination sound like stopped being a question: the answer was always a lookup. Same discipline in the Periodic Table (coordinates first, content second) and Inventor Strudel’s grammar metaphor. Get the grammar onto paper, then build the surfaces that read it.

decisions I’d defend

Faithful fingering over a “modernized” UX. I could have flattened the OM-108’s combination grammar into one-button chord types: pick a chord from a list, hit it. I didn’t. The combination rules are the instrument. Pressing MAJ + 7TH one column to the left to get sus4 is the trick that makes the original Omnichord more than a chord pad. The hint overlay exists because the grammar is unobvious. The grammar exists because that’s the whole point.

Hardware aesthetic, not skeuomorphic kitsch. The chassis reads as a photographed object, not a Photoshop bevel. Cream body, brass strumplate, ivory keycaps, navy silk-screen print, brass screws. Suzuki is a Japanese company, so the chassis carries the single katakana panel mark オムニコルド over the left-hand keys, also the title of the web edition: Omunikorudo, the way a Japanese speaker reads “Omnichord” back. Naming the build by its katakana reading is the same period-fidelity rule that runs the rest of the chassis.

Every surface is a semantic design token. No drop shadow without something casting it, no rounded corner without a manufacturing reason. The rules live in a mem://style/visual-direction memory entry the AI tooling consults on every change, so the next time someone tries to add a dark-mode charcoal button, it’s already vetoed. Same pattern as SPF’s decision log and the Periodic Table’s Lab Notebook.

Cut the looper. The OM-108 has a rhythm section, and the obvious web extension is a loop recorder. I shipped the rhythm section and cut the looper. Recording pulls the product toward DAW-lite, which is exactly the product I’m not building. The wedge is playing, not producing. The rejection is logged in project memory so it stays rejected, including from me, on a Tuesday, three months from now.

what I learned

Recreating a real instrument is a spec problem first. I authored the full chord-combination truth table before writing a single component. Once the table existed, the audio engine and the interface both fell out of it. Spec discipline up front is what made the AI tooling cheap; without it I would have been arguing with the model for weeks.

Audio on the web is a latency-and-lifecycle problem, not a sound-design one. Auto-init on first input, ESC and tab-away as panic-stops, a single shared audio engine: together they solved 90% of the “feels broken” reports before they happened. Sound design is downstream: if the lifecycle is wrong, no patch sounds good.

Authenticity is a constraint, not a flourish. The OM-108’s grammar produces some chords no keyboard player would invent and refuses to produce others. Preserving the gaps was load-bearing: a “free chord” mode, a hidden rhythm row, a smoothed strum response, any of them would have shipped a different, lesser instrument.

The demo is the pitch. A zero-setup playable URL beats any screenshot or video. People decide whether the project is real in the first ten seconds: same logic as SPF’s no-signup demo and Inventor Strudel’s audio-on-first-click.

what would prove it

Omunikorudo has no analytics, on purpose. If it did, these are the three things I’d be looking at:

• Time to first sound predicts return visits. Auto-init on first input is the whole bet on onboarding. If users who hear a chord within three seconds of landing come back, the audio lifecycle is doing the work. If they don’t, the bottleneck isn’t audio, it’s the chord-row grammar: the hint overlay needs to teach harder, sooner.
• Offset combinations separate players from strummers. Users who only press one button at a time are playing a chord pad. Users who reach for MAJ + 7TH one column to the left (the trick chord, sus4) are playing the instrument. Retention divergence between those two cohorts would say the grammar earned its faithfulness; convergence would say the hint overlay isn’t doing enough teaching.
• HOLD mode usage tracks songwriting intent. People who latch a chord and walk away with it are writing, not just playing. Frequent and long HOLD usage would mean songwriters have found this; rare and brief HOLD usage would mean the instrument is novelty, and the no looper decision needs a different hedge.

Two risks the design has to keep refusing:

• Plateau after the novelty. Without a recorder, looper, or exporter, the instrument has a ceiling. The looper got cut on purpose, and honoring that cut means accepting that some users will hit the ceiling and move on. The hedge is making the demo good enough that they leave glad, not bored.
• Browser audio drifts under your feet. Safari, Chrome, Firefox handle Web Audio differently, and iOS adds gesture requirements desktop doesn’t. The shared-engine architecture and the ESC/tab-away panic-stops mitigate but don’t eliminate. Every browser update is a small risk to the lifecycle, and the only real defense is keeping the engine code legible enough to fix on a Tuesday.

method extracted: Interface grammar

Omunikorudo is the project. Interface grammar is the reusable method underneath it. The object already had a grammar. The browser version had to learn to speak it.

This pattern preserves buttons, modes, timing, chord behavior, affordances, and expectation when translating physical or legacy workflows into software.

See the Methods index.

what’s next

Four next moves, in order:

• MIDI in/out so the instrument can drive other gear and be driven by it
• Preset save/load with shareable URLs: a tone you stumble into can become a link
• A real mobile gesture model for the strumplate: touch on phones is a different instrument than mouse on a laptop
• A second chassis (OM-300, or the Q-Chord) once the chord-grammar engine is general enough to host a different layout

No paid tier planned. Stays free and playable at omnichord.hosette.net.