Drum machine · hy4

We need build single self-contained index.html. Need likely use browser tool to inspect. Need carefully implement robust Web Audio scheduling, distinct synthesis, playback changes without duplicate sequences, stop cancels future hits playhead resets first step. Need perhaps visual step buttons 4x16, labels, controls. Need initial audible pattern. Need audio unlocked via user gesture. Need BPM range 60-180 and editing affects playback. Need playhead highlights current step. Need start playback potentially Play button gesture. Need consider scheduler architecture precise.

We should make polished interface perhaps dark modern. Need no external resources. Need use browser initial and representative checks. Need understand browser tool action capabilities; can inspect DOM/console, click, screenshot. We can also potentially use JS via browser? Tool doesn't list evaluate, but inspect perhaps DOM and console. Could embed test hooks/data attributes to make readouts accessible via DOM. We can instrument status text and current step attribute. Need perhaps use browser click actions. We can likely use screenshot and inspect results. We have 15 minutes. Let's design.

Audio scheduling:
- AudioContext lazily created on Play user gesture, resume().
- BPM as integer from range.
- 16th duration = 60 / bpm / 4.
- Use lookahead scheduling with setInterval 25ms and scheduleAheadTime 0.1s perhaps. Need editing steps/BPM affect playback without duplicate sequences. One persistent scheduler interval and one AudioContext, sequence timeline. Toggle just pattern state; scheduler reads it when each step scheduled. But with lookahead ~0.1s, toggles up to 100ms before hit may not affect already scheduled hits; requirement "Editing steps or BPM must affect playback without creating duplicate sequences." Ideally need immediate effect. Could schedule one step at a time with shorter lookahead or use dynamic param/time. Let's think robustly.

Use a `setInterval` at e.g. 25ms schedule notes up to 0.1 sec ahead. Changing BPM will adjust nextStepTime increments for future scheduling, but already scheduled hits might stay. Editing steps after scheduled could miss immediate effect. Could use very small lookahead (e.g. 0.03s) and schedule via setTimeout exact? Web Audio needs ahead scheduling for precision. Another approach master periodic timer with `setTimeout` per step that schedules at audioCtx.currentTime (slightly ahead), and use Web Audio oscillator envelopes. BPM changes on next step. But JS timer drift maybe okay for toy. Or use scheduler that recalcu
lates and cancels scheduled future hits whenever pattern or BPM changes. Track scheduled voice nodes / gain nodes; stop/cancel future hits. We can implement `cancelPendingSounds()` on pattern or BPM changes, rewind scheduler cursor to first unsounded step based on current time? Complex.

Alternative simple scheduling using one `setTimeout` per step and highlighting tied to audio time. Each step fires:
```
function playStep() {
  if (!playing) return;
  const current = currentStep;
  highlight(current);
  trigger voices based on pattern at that exact moment; // toggle affects within one step
  const stepDuration = 60/bpm/4 * 1000; // reading current BPM every step
  timeout = setTimeout(playStep, stepDuration);
  currentStep = (currentStep+1)%16;
}
```
No duplicate sequences if guard with single `playToken` / clearTimeout. Stop `clearTimeout` cancels future hits and resets currentStep 0. BPM read at each step. Since synthesis schedules itself at audioCtx.currentTime + .005 and envelope. No duplicate intervals. Distinct sounds. Audio accuracy timer jitter maybe modest but okay, and requirement Web Audio API is met. But "synthesize enabled drum voices" and "BPM control affects playback" yes. Could use Web Audio scheduling with lookahead for robust timing but a single setInterval. Let's explore best architecture for both accurate timing and immediate edits.

Use audio clock schedule with lookahead:
- `nextNoteTime`, `nextStepToSchedule`.
- setInterval scheduler, while nextNoteTime < ctx.currentTime + 0.1:
  - schedule enabled voices at `nextNoteTime`.
  - schedule UI highlight via queue [(step, time)] and requestAnimationFrame update.
  - advance `nextNoteTime += sixteenthDuration()` using current BPM at scheduling point.
- On BPM change, any notes already in lookahead (0.1 sec) scheduled at old spacing. Could cancel pending voices. Maintain scheduled events with time > ctx.currentTime + ~0.005 and associated source/gain nodes; cancel/stop them. Then reset `nextStepToSchedule` to first step not yet heard and `nextNoteTime` to soon, recompute from last heard boundary. Need know last played step/time precisely. We can track lastAudibleStep and lastNoteTime. On change we could set scheduler to recompute starting from `lastAudibleStep+1` at `lastNoteTime + newDuration`; if BPM changed mid-step, desired next hit maybe based on last hit + new duration. Cancel any scheduled events. But UI queue too. This is manageable.

Yet toggling pattern: if scheduled lookahead notes should reflect current pattern, cancel all future voices and reschedule from `nextUnheardStep` at its original time with current pattern. Could maintain state. Or simpler lookahead 0.03s (30ms) and BPM changes may still have 1 scheduled note; browsers likely checking by reading visual step and status rather than audio events. But explicit requirement "editing steps or BPM must affect playback without creating duplicate sequences" likely means avoid restarting scheduler/creating duplicate intervals when controls changed; reading live state okay. Typical test may inspect number of intervals? Maybe they test toggles and BPM change while playing and ensure one playhead. The implementation can keep a single interval and derive timing each tick. Need no duplicate sequences.

Could implement a hybrid: use a single `setInterval(scheduler, 25)` and schedule only one step when due via `currentTime`, with no lookahead beyond minimum 5ms. JS timer still calls via Web Audio clock, but scheduling that note immediate. Use `nextNoteTime`; on each timer tick:
```
while (nextNoteTime <= ctx.currentTime + 0.01) {
  scheduleStep(step, Math.max(ctx.currentTime+0.005,nextNoteTime));
  ui queue...
  nextNoteTime += 60/bpm/4; // current BPM at scheduling point
  step=(step+1)%16;
}
```
If BPM change, notes not scheduled yet (nextNoteTime could be up to 25ms away) use new duration. Pattern read at schedule time. Changing pattern within 10ms of upcoming sound may not affect because scheduled, acceptable practically. No duplicate sequences. Stop clears interval and maybe cancel scheduled sources; robust. To ensure no future sounds, stop all active voices scheduled/active at stop. Need maintain `activeNodes` set and stop each source at currentTime, maybe disconnect. Could use a master `playbackGain`? On stop, ramp master gain to zero then restore? We want stop cancels future hits. We can call `.stop()` on all scheduled source nodes (oscillators/buffer sources) at currentTime. Also envelope gains with scheduled ramps—source stop suffices. For AudioBufferSourceNode and OscillatorNode. Need handle source `.stop()` possibly called twice—catch. Keep nodes with `.onended` remove/disconnect. For noise buffer, one per clap/snare/hihat hits. Use master gain and perhaps compressor.

A more straightforward architecture with setInterval and small schedule horizon:
- On Play:
  - if `playing` return.
  - create/resume context.
  - playing=true; runId++.
  - currentStep=0; nextNoteTime=ctx.currentTime + 0.05; schedulerStep=0.
  - start setInterval(scheduler, 15 or 20ms).
  - Also immediate call scheduler perhaps schedules first step at +0.05.
  - UI highlight maybe first step when actual time arrives, via queue and requestAnimationFrame.
- `scheduler()`:
```
if (!playing) return;
const horizon = ctx.currentTime + 0.03;
while(nextNoteTime < horizon) {
  const time = Math.max(nextNoteTime, ctx.currentTime + 0.003);
  triggerPatternStep(schedulerStep, time);
  highlightQueue.push({step,time});
  nextNoteTime += secondsPerStep(); // read current BPM right now
  schedulerStep = (schedulerStep+1)%16;
}
```
At 180 BPM step=83.3ms, timer 15ms catches within horizon. At 60 BPM step=250ms.
- UI animation frame:
```
while queue length && queue[0].time <= ctx.currentTime + 0.005 { currentStep=next.step; shift }
updatePlayhead(currentStep)
```
But if tab hidden requestAnimationFrame stops; maybe scheduler should also update visual based on `setTimeout`. Could include UI queue and rAF loop only while playing. Fine.
- On BPM input, if new duration changes, `nextNoteTime` was computed based on prior step duration. We can adjust nextNoteTime to reflect new duration from last scheduled step:
  - Keep `lastScheduledTime` (time of most recently scheduled step) and `lastScheduledBpm` perhaps.
  - A pending step hasn't been scheduled until within 30ms. When BPM changes after step at T scheduled with old interval, nextNoteTime = T + oldDuration. We can update to T + newDuration (clamped to currentTime + 0.005). If newDuration shorter and T+newDuration is in past, run scheduler quickly. This makes BPM effective immediately. Need avoid weird if multiple steps scheduled? Horizon 30ms and min step 83ms means at most one future note scheduled. Yes. So:
```
function setBpm(v) {
 const now = ctx?.currentTime||0;
 bpm=v;
 if(playing && lastScheduledTime != null) {
  const candidate = lastScheduledTime + secondsPerStep();
  nextNoteTime = Math.max(now + 0.01, candidate);
  // But if candidate < now, we shouldn't skip multiple? At most one step; triggering late is okay.
 }
}
```
Could just let nextNoteTime retain old spacing for one boundary; "responds to BPM change" still next boundary after that. But adjust is better. However if candidate < currentTime + .01, schedule next immediately; then after scheduling, nextNoteTime = time + newDuration. This means beat phase reset based on last hit. Fine.
- Pattern toggles: if a step in pending 30ms is already scheduled, can't unschedule unless cancel nodes for that step. We can keep `pendingHits` keyed event time and nodes. On toggle, cancel any scheduled voices whose time > now and reschedule enough? But need not schedule with stale pattern. Could implement smaller horizon 0.01s or direct scheduling at boundary; user toggles likely more than 10ms before. But requirement "Editing steps ... affect playback" could be tested via behavior or code. We can manage robustly.

Alternative scheduling using Web Audio `setValueAtTime` gates per voice to dynamically control pattern at each step with a looping schedule? Could keep running oscillator/noise and envelopes scheduled per step, and toggling resets gain automation for future notes—complex.

Maybe consider no lookahead at all: setInterval 5ms and at each tick check `ctx.currentTime >= nextNoteTime`, then schedule at `ctx.currentTime + 0.002` (2ms). Pattern and BPM read at exact boundary; controls affect next step. No pre-scheduled future sounds. Timer jitter <=5ms; Web Audio scheduling still used. This avoids cancel pending. Could implement:
```
const TICK_MS = 10;
setInterval(() => {
 if (!playing) return;
 const now=audioCtx.currentTime;
 if (now + 0.008 >= nextNoteTime) {
   const step=schedulerStep;
   triggerStep(step, now + 0.003); // patterns live
   showStep(step);
   schedulerStep=(schedulerStep+1)%16;
   nextNoteTime = now + 0.003 + secondsPerStep(); // or += old interval? 
 }
}, 8)
```
Since only one callback active at a time and no duplicate intervals. At most one step late. BPM read at each step. Playhead updates at sound time. Stop clears interval; no future hits. Audio timing based on JS timer but decent. Could use `setTimeout` dynamically with `nextNoteTime` distance and audio clock; but easier setInterval. This is likely acceptable. "using Web Audio API" yes, oscillators/noise with envelopes. "synthesize ... from oscillators/noise and envelopes" yes. No requirement sample-accurate scheduler. Could perhaps use lookahead 0.025 and still good. But the strongest interpretation of controls affecting playback is no scheduling notes ahead of edits. With near-zero lookahead, guarantee. Let's use one-step scheduling at exact audio time with interval 5ms, maintain accurate timestamp:
```
let nextNoteTime = ctx.currentTime;
function scheduler() {
 let now = ctx.currentTime;
 if (now + 0.006 >= nextNoteTime) {
   let when = Math.max(now + 0.002, nextNoteTime);
   scheduleStep(schedulerStep, when);
   visualQueue...
   let dur = 60 / bpm /4;
   nextNoteTime = when + dur;
   schedulerStep=(schedulerStep+1)%16;
 }
}
```
At 180 bpm, dur 83ms; interval 5ms; fine. In inactive tab, setInterval throttled to 1s, scheduler checks only one step and skips missed steps: no duplicate sequence, playback becomes paused while hidden. Could while loop catch up? Would burst many sounds. Better skip by setting nextNoteTime=now + dur if large lag. On each tick:
```
if (now > nextNoteTime + dur) { // tab throttled -> resync
  nextNoteTime = now + 0.002;
}
if (now + .005 >= nextNoteTime) schedule...
```
No duplicate sequences. Playhead advances one per audible note. Good.

Could use `requestAnimationFrame` for UI highlight queued note. But scheduleStep happens ~2ms before audio time; we can set visual via `setTimeout` to when - now in ms. Yet setTimeout could produce duplicate if stop/start; use runId checks. Or use rAF loop comparing audioCtx.currentTime. Simpler: `visualQueue.push({step,time})`, start a single rAF loop on play. On stop cancelAnimationFrame. Need ensure no duplicate rAF loops. Use `rafId` guarded. In loop:
```
while(queue[0] && queue[0].time <= ctx.currentTime + 0.002){ visualStep=queue.shift().step; }
if visualStep !== last... updateDOM.
rafId = requestAnimationFrame(visualLoop)
```
Single loop. Stop cancels. Play starts one only. Or schedule via `setTimeout` and clear all pending on stop—track ids. rAF easier.

Need highlight step 0 before first actual hit? Requirement "highlight current step" during playback. At Play, could set currentStep=0 and highlight immediately while first note scheduled at currentTime+0.03. Then actual first sound perhaps at +0.03. Using direct scheduler set nextNoteTime=ctx.currentTime + 0.04; call scheduler after start; first event scheduled 2ms before. Playhead initially maybe -1 until first hit. Better set display step 0 at Play so clear visual response. Could update `currentStep=0; updatePlayhead()` and schedule first hit at `ctx.currentTime + 0.06`. Then visual loop sets when sound. If no current step before first 60ms, slight delay. Could highlight first step immediately and then subsequent at exact hits. Need avoid queued event for first step shifting weird. We can set `visualStep=0` and on Play highlight. Then at first hit queue step 0 which doesn't change DOM. Subsequent step 1 etc. Initially starting at step 0. Stop resets to 0 and perhaps highlight remains? "Stop ... resets playhead to first step." Might mean highlight first step or no playhead? Display reset first step. We can set currentStep=0 and highlight it with a neutral "ready" class. Or reset highlight to no current step? Need carefully accommodate tests. They may expect "playhead restarts from first step" and visual first column highlighted on stop or upon start. Could maintain currentStep=0 and highlight step 0 even stopped. This clearly "resets playhead to first step." Add `is-playing` class perhaps. Use `data-current-step="0"` on grid and step elements `data-active-step`. Then browser inspect can read. Likely tests use DOM textual state. We can add status readout "Stopped · Step 1" or "Playing · Step 3 · 120 BPM". Need make behavior checkable.

Grid representation:
- 4 rows with label and 16 buttons. Use `button.step` with aria-label like "Kick step 1", `aria-pressed`, `data-row`, `data-step`, class `on` and `playhead` when current column.
- Group headers? Could put beat markers 1..16 above grid. Grid CSS with label column + repeat(16, 1fr). Need responsive. 16 columns might be cramped at 1200x800; each ~48px if content width 900. Fine. On narrow screens use overflow-x auto and min-width perhaps 820px. Browser viewport 1200x800. Need design nicely.
- Four labeled rows. Label text and maybe dot/color. Distinct row accent colors.
- Initial pattern:
  - Kick steps 0,4,8,12 (four-on-floor) maybe additionally 10? simple audible.
  - Snare steps 4,12 (backbeat)
  - Hi-hat even steps 0,2,4,6,8,10,12,14 (eighth notes)
  - Clap maybe step 12 or 4,12? To make all voices audible, clap step 7/15 or layered with snare step 12. Pattern could be kick [0,4,8,10,12], snare [4,12], hh [0,2,...], clap [12,15]. Good simple.
- Toggling button updates pattern and visual and aria.
- Play, Stop, Clear. BPM range 60-180 with numeric display, maybe number input? Requirement "BPM control from 60 to 180" a range suffices. Add `<input type="range" min="60" max="180" step="1" value="112">`, output. Maybe also numeric input? A range with output is enough. Use BPM 120 perhaps. A number field could allow direct test typing? Browser tool can click range but not drag perhaps. Tests could programmatically set value. Add robust `input`/`change` listeners. We can have `<input type="number" min=60 max=180>` plus range? Requirement singular control. Could include range and numeric readout, no need. For easy browser checks, range drag action available. Need ensure output text changes. Could maybe expose `window.__sequencer` for programmatic diagnostic? Not necessary, but could be useful for our browser checks via DOM? Browser inspect doesn't provide evaluate. We could maybe click at positions. But providing hidden status with BPM and step readout helps.
- Play button toggles? Requirement Play and Stop separate; Play should not stop if already playing. Use distinct buttons. On Play while playing, no-op. On Stop, clear interval/rAF, cancel active audio sources, reset currentStep=0, schedulerStep=0, visualQueue=[], status. Clear doesn't stop playback. `clear` sets all false, updates buttons. Pattern retained after stop; Clear only disables all.
- Audio unlock through user gesture: `ensureAudio()` called on Play click (and maybe any step click? "Unlock audio through a user gesture"; Play is gesture). Create AudioContext on first user gesture. Could additionally unlock on button pointerdown/keydown to be safe. Use `new (window.AudioContext || window.webkitAudioContext)()`. Call `resume()` from click. If context suspended, `await ctx.resume()` before start. Need not block scheduling with async perhaps Play async. `playBtn.addEventListener('click', async () => { await ensureAudio(); start(); })`; robust.
- Could unlock on any control click by attaching `pointerdown` to document once? Requirement says through user gesture—not necessarily autoplay attempt. We can `ensureAudio` in Play. Maybe adding `window.addEventListener('pointerdown', unlockAudio, {once:true})` would create context on any gesture but only Play starts; okay. But no need and maybe test expects audio context state. We can add `ensureAudio()` in step button click? Then toggling creates context and resumes—still gesture. Could do so to ensure. But if step click triggers context, no sounds. Fine.
- Distinct percussion sounds:
  - Kick: sine oscillator with pitch envelope from ~150Hz to 45Hz over 0.12s, gain envelope fast attack/decay 0.5s. Maybe click via tiny noise? Distinct enough.
  - Snare: noise through highpass/bandpass + triangle oscillator ~180Hz; noise envelope ~0.18s, tonal body ~0.1s. Use generated noise buffer (a 1s AudioBuffer) with `AudioBufferSourceNode`; random values. No audio files.
  - Hi-hat: noise through highpass 7000Hz plus bandpass maybe 10k, very short 0.05s envelope; perhaps metallic oscillators (square at ratios) too. But noise+highpass distinct.
  - Clap: multiple short noise bursts with bandpass ~1400Hz, gain envelope with ramps at offsets 0, 0.012, 0.024, 0.038 plus tail 0.18s. Need implement from noise buffer and envelope. Could create 3 or 4 bursts using one noise buffer source and gain automation with multiple pulses, or several sources. Better use gain automation:
```
gain.gain.setValueAtTime(0, t);
[0,0.012,0.025].forEach(o=> {
 setValueAtTime(0.0001,t+o)
 linearRampToValueAtTime(level,t+o+0.002)
 exponentialRampToValueAtTime(0.0001,t+o+0.012)
});
setValueAtTime(level*0.55,t+0.038);
exponentialRampToValueAtTime(.0001,t+0.038+.14)
```
Need avoid automation overlaps. Set discrete pulses using setValueAtTime at boundaries and exponential decay. At each pulse:
```
gain.setValueAtTime(0.0001, start);
gain.linearRampToValueAtTime(level, start+0.001);
gain.exponentialRampToValueAtTime(0.0001, start+0.012);
```
Then final at 0.038, decay 0.16. This could work. Connect bandpass filter -> gain -> master.
  - Hi-hat: noise buffer with highpass at 6000 and maybe bandpass at 9000; gain attack 0.001, decay 0.05. Could add 6 square oscillators at inharmonic frequencies into highpass; but no need.
  - Snare: noise highpass 1200, gain decay 0.18; plus triangle oscillator 180Hz -> gain decay 0.11. Distinct.
  - Kick: sine oscillator pitch envelope and gain. Maybe click with highpass noise tiny. Could just oscillator.
- master chain: `masterGain` -> `compressor` -> destination perhaps. Set master gain .75. Use DynamicsCompressorNode threshold -12, ratio 4, attack .003, release .1. Not necessary but nice. Need not use external.
- Cancellation:
  - Maintain `activeSources` Set of `{node, stopTime?}`? On every source creation:
```
function track(source, stopAt) {
 activeSources.add(source);
 source.onended = () => { activeSources.delete(source); try disconnect...}
 source.start(when); source.stop(stopAt);
}
```
But for oscillator, gain envelope might run; source.stop at stopAt. For stop, need cancel all future hits. Call each source.stop(now) and disconnect? For sources scheduled in future, calling stop(now) where now < start time may cause no output and onended? Web Audio spec allows stop time before start? It may produce no sound; calling stop before start should be okay. But if we call `.stop(now)` on a source that already had `.stop(end)`, spec says latest call replaces prior stop time. Good. Need catch `InvalidStateError` if not started? We call start at schedule. All tracked sources started. Need potentially disconnect envelope nodes; source `onended` disconnect all chain nodes. Store nodes group and remove. Could define activeVoices Set of objects `{sourceNodes, nodes}`; when source ended decrement and disconnect group. Simpler:
```
const activeVoices = new Set();
function registerVoice(sources, nodes, start, stop) {
 const voice={sources,nodes,ended:0};
 activeVoices.add(voice);
 sources.forEach(s => {
   s.onended=()=> { ... if(++ended===sources.length) disconnect all; activeVoices.delete(voice);}
   s.start(start);
   s.stop(stop);
 });
}
function cancelAllVoices() {
 const now=ctx.currentTime;
 activeVoices.forEach(v=>v.sources.forEach(s=> {try{s.stop(now)}catch{}}));
 // They may not fire onended if stop before start; manually disconnect after timeout?
}
```
If stop(now) on a future source with start at t>now: MDN says if stop called before start time, sound never plays. It should fire ended? likely. But if not, no leak? Could also immediate disconnect all nodes:
```
setTimeout(() => { nodes.forEach(n=>n.disconnect()); activeVoices.delete(v);}, 50)
```
Audio nodes connected but silent. We can manually disconnect after stopping, but if we disconnect immediately, any currently sustaining tail cut off, which is desired on Stop. Future sources disconnected. For `onended` later, disconnect again harmless. Then clear set. This ensures cancellation.
```
function cancelVoices() {
 for voice of activeVoices:
   voice.sources.forEach(s=> {try{s.stop(ctx.currentTime)}catch{}})
   voice.nodes.forEach(n=>{try{n.disconnect()}catch{}})
 activeVoices.clear()
}
```
Note: calling stop() on sources that have already ended might throw; catch. Since activeVoices may contain ended source if `onended` not yet; catch. Need not cancel scheduled automation. Fine.
- On Stop, clear `schedulerId`, `rafId`, `visualQueue.length=0`, `playing=false`, `schedulerStep=0`, `currentStep=0`, `nextNoteTime=0`, `lastStepTime=0`; call cancelVoices; updatePlayhead; status. Need ensure if scheduler callback racing from earlier? JS single-threaded, clear interval stops future; current callback finishes. `playing` false before clear. Good.
- On Play:
```
if(playing) return;
await ensureAudio();
if (playing) return; // async race guard
playing=true;
runToken++;
schedulerStep=0;
currentStep=0;
visualQueue=[];
nextNoteTime=ctx.currentTime + 0.04;
updatePlayhead();
schedulerId=setInterval(scheduler, 8);
scheduler(); // might not schedule first because +40ms; visual initial.
startVisualLoop();
```
Need if Play double-click before await returns: `starting` flag. Use `let starting=false;` set true; await; start; set false; finally. Or synchronous ensureAudio can call resume without await, but context may still be suspended. We can do:
```
async function ensureAudio() {
 if (!ctx) create...
 if(ctx.state !== 'running') await ctx.resume();
}
```
and guard `if(starting || playing)return; starting=true; try { await ensureAudio(); startPlayback(); } finally {starting=false;}`
- `startPlayback()` creates a single interval. Need not call scheduler twice? setInterval plus call. Use `tick()` once.
- status:
```
function refreshStatus() {
 const state = playing ? 'Playing' : 'Ready';
 status.textContent = `${state} · step ${currentStep+1}/16 · ${bpm} BPM`;
 grid.dataset.currentStep = String(currentStep);
 grid.dataset.playing = String(playing);
 tempoReadout.textContent = bpm + ' BPM';
}
```
On each playhead visual update, call `setCurrentStep` which updates buttons and status. Could use CSS `button.step.is-current` and maybe column backdrop. Grid container might have a vertical playhead overlay; easier add class to buttons in current column. Need also beat markers highlight. Use `document.querySelectorAll('[data-step="n"]')`. Could store `cellsByStep`. On update, remove `.is-current` from prior column's 4 cells + marker; add to new. Also `aria-current="step"` perhaps only first row? Could set. Add `.step.is-current` ring, and perhaps row cells with background change. Use CSS:
```
.step.is-current { outline:2px solid #fff; box-shadow...}
.step.is-current::after? 
```
Would only outline each of 4 buttons in column, creating column. Also add `.beat-marker.is-current`.
Maybe a vertical bar with CSS grid? Could have an overlay `#playhead` positioned with CSS variable `--playhead-step` over grid steps, but complexity. Buttons enough.
- `.step.on` background accent per row using CSS custom property `--accent` on row. Use button style:
```
.step {
 background:#1a2230;
 border:1px solid #344054;
}
.step.on {
 background: color-mix(in srgb, var(--accent) 75%, #101827);
 border-color: var(--accent);
 box-shadow: inset 0 -3px 0 rgba...
}
```
`color-mix` supported in modern Chromium likely; can avoid for compatibility by defining `--accent-on` per row and use that. Use CSS variables and inline style on row? Could set `.track.kick {--accent:#ff6b4a; --accent-soft:#6d2b24}`. Or style attribute on row via JS? Keep simple:
```
.step.on { background: var(--accent); color:#08111e; border-color:...}
```
Distinct row colors, bright. Current outline white. Need track buttons all same visual. Maybe use accent background with low opacity using `rgba` custom. Define track-specific CSS. Could use CSS `background: var(--on-bg)` where each track defines values. Great.

Layout:
```
<div class="app">
<header>
 <div class="eyebrow">Web Audio · 16-step</div>
 <h1>Pulse Grid</h1>
 <p>...</p>
</header>
<section class="transport">
 <div class="buttons">
  <button id=play ...>▶ Play</button>
  <button id=stop ...>■ Stop</button>
  <button id=clear ...>Clear</button>
 </div>
 <div class="tempo">
  <label for=bpm>Tempo <output id=bpmValue>120 BPM</output></label>
  <input id=bpm type=range ...>
  <div class=range-labels><span>60</span><span>180</span></div>
 </div>
 <div class=status id=status aria-live=polite>Ready · step 1 · 120 BPM</div>
</section>
<section class=sequencer aria-label="16-step drum sequencer">
 <div class=beat-ruler> <span class=label-spacer></span> <button? marker labels? </div>
 <div class=tracks id=grid>
 ...
 </div>
</section>
<footer maybe instructions>
```
Need align grid: Could make one big CSS grid with header row plus 4 track rows. Use JS generate all:
```
<div id="sequencer" class="sequencer">
 <div class="ruler">
  <div class="ruler-label">STEP</div>
  <div class="beat-marker" data-step="0">1</div>...
 </div>
 <div class="track" data-track="kick" style...>
  <div class="track-label"><span class=color-dot></span><strong>Kick</strong><small>low sine</small></div>
  ...16 buttons
 </div>
...
</div>
```
Each `.track` and `.ruler` `display:grid; grid-template-columns: 128px repeat(16,minmax(28px,1fr)); gap:6px;`. In a horizontally scrollable container with min-width: 900px. Buttons with `aspect-ratio:1; min-height:34px`. At 1200 viewport, app max-width ~1120, enough. On mobile overflow scroll. Use beat group boundaries via border or margin: steps 0,4,8,12 class `.downbeat`, perhaps background lighter; markers with bold numbers and small "1 & 2 &"? 16 markers could show 1, 2, 3,... or subdivisions. Could show numbers 1..16 and emphasize quarter beats 1,5,9,13. Better label `1`, `&`, `2`, `&`, etc? Since 16th notes in 4/4, markers could show `1 e & a 2 e & a ...` but 16 small columns. Use 1..16 with downbeats highlighted and group label. Maybe label markers `1`, `·`, `·`, `·`, `2`, ... visually. Could set `data-label`: for step index:
  - if i%4==0 => beat number i/4+1
  - else => "·" or "e/&/a" tiny. Use labels `1,e,&,a,2,e,&,a,...`. Good. Add ruler caption maybe "1 bar / 16 sixteenth notes".
- Group boundaries with `.beat-start` border-left or thicker gap. Because CSS gap fixed; use box-shadow left accent on start columns. Could add `.step-bar-start` with margin-left? Simpler marker `border-left:2px solid`. Buttons at i%4==0 get `box-shadow` perhaps conflicts with on. Use `.step.downbeat { border-left:3px solid #647...}`.
- Button numbers maybe include tiny step number inside? Could show numeral always in center with low opacity. `.step::before` content attr(data-index) maybe. But toggled state could obscure. Could use `<span>1</span>` and CSS. This gives 16x4 grid numbers; perhaps too cluttered. Use tiny number upper-left perhaps:
```
.step {font-size:10px; color:#7d8a9c;}
.step.on {color:#07111d}
```
Could just show `1`..`16`, useful. But visually simpler to show dot when on. Use `button` with span `data-step` number. Nice.

Need test accessibility maybe `aria-pressed`. Keep.

Potential browser test actions:
- `browser reload`, `inspect`, `screenshot`. Need see initial output and console. Need possibly click step and Play. Need use coordinates from screenshot. Could use `browser inspect` to get DOM details maybe returns tree. We'll call.
- Need check playhead advances across grid and responds to BPM change. Could use status text as DOM. At 120 BPM, step=125ms. Browser screenshot timing may catch current. `inspect` might show status. To test BPM change via drag range, use `browser drag` from a coordinate to another. Need determine coordinates from screenshot. Could alternatively use keyboard: click range then key ArrowRight repeatedly; but from 120 to perhaps 180 would need 60 presses. Could set via click at right side of slider (range usually jumps to clicked position), so click x near right endpoint. That changes BPM to near max. `browser click` on range at x position. Need ensure controls positions. Could maybe add number input and use browser type with text. We can type into number input using click and type. But range is required; adding a number input as companion could facilitate direct BPM selection. Let's consider adding both a range and a numeric field linked:
```
<input id="bpm" type="range" min=60 max=180 value=120>
<input id="bpmNumber" type="number" min=60 max=180 value=120>
```
Would that be two BPM controls? Fine. But requirement "a BPM control from 60 to 180"; range alone enough. Yet a numeric field gives testable input and user convenience. Maybe include `output` styled as a number input? Could use `<input id="bpmNumber" type="number" ... aria-label="BPM value">` next to range, with sync. This is useful. But more code and potential duplication; can handle. Let's do range + number field. Need ensure clamping on number input; if user clears it temporarily, avoid setting bpm to 60 while typing; use `change` event and `input` only if valid. Range `input` live. Number input `change` (and maybe Enter via browser type) will set. To test, `browser type` may send input events and change maybe on blur. Could use `blur` handler. Add both `input` if valid and `change`.
```
function setBpm(value, source) {
 const parsed = Number(value);
 if(!Number.isFinite(parsed)) return;
 const clamped=Math.min(180,Math.max(60,Math.round(parsed)));
 bpm=clamped;
 bpmRange.value=String(bpm);
 bpmNumber.value=String(bpm);
 bpmOutput? no need.
 updateStatus();
 if (playing && ctx) {
   const now=ctx.currentTime;
   const dur=stepDuration();
   // Re-base the next note from last hit / currently scheduled step.
 }
}
```
Need decide scheduling architecture with immediate BPM effect. We can use `setTimeout` dynamic next step and no lookahead. Let's design carefully around BPM change.

Option 1: Web Audio clock + setInterval 5ms:
State:
- `nextStepTime`: audio time at which next step should fire.
- `nextStepIndex`: index to play.
- On each tick, if `ctx.currentTime + 0.006 >= nextStepTime`, schedule at `when = Math.max(ctx.currentTime + 0.002, nextStepTime)`. Since we call at near boundary, likely nextStepTime > currentTime maybe by <=6ms, so `when=nextStepTime`. Need ensure not in past. If in past, `when=currentTime + .002`.
- Trigger step immediately at `when` (2-6ms ahead) and queue highlight at `when`.
- `nextStepTime = when + stepDuration()` (current bpm read now).
- `nextStepIndex=(nextStepIndex+1)%16`.
- If BPM changes between steps, `nextStepTime` was based on old duration. Need adjust:
   Track `lastStepTime` (the `when` of most recently fired/scheduled step), and `lastStepBpm` maybe not needed.
   On bpm change:
```
const newDuration = stepDuration();
if (playing && lastStepTime !== null) {
  const proposed = lastStepTime + newDuration;
  nextStepTime = Math.max(ctx.currentTime + 0.002, Math.min(proposed, ???));
}
```
Since no more than one step pending, nextStepTime equals lastStepTime + oldDuration. Set to lastStepTime + newDuration. If proposed <= currentTime (faster BPM changed after old interval already elapsed but tick hasn't fired? tick every 5ms so unlikely), clamp to now+0.003, which will schedule next step on next tick. If proposed > currentTime + .003, use it. If BPM slows from 60 to 180 at a moment near old boundary, new duration 83ms; proposed maybe in past, so immediate next step. Good. If speed decreases from 180 to 60, new duration 250ms; proposed possibly future 200ms. Good. This rephases from last step, which is intuitive. Need `lastStepTime` set at schedule. On Play, could set `lastStepTime = ctx.currentTime` and `nextStepTime = ctx.currentTime + .04` but then bpm change before first step would set nextStepTime = lastStepTime + newDuration (e.g., 125ms) delaying first step based on BPM. Maybe that's okay, but Play should start promptly. Could instead set first step time at `ctx.currentTime + 0.02`, and on BPM change only adjust after at least one step. Need track `lastStepTime=null` until first. Then no adjustment; nextStepTime remains +.03. After first, set. Fine.
   On BPM change while stopped just update status.
- If tab throttled/late:
```
const now=ctx.currentTime;
if (now > nextStepTime + 0.05) {
  // skip missed steps and re-anchor without burst
  nextStepTime = now + 0.006;
  // Keep sequence index, playhead not rapidly advance.
}
```
But with 5ms interval and note durations 83-250ms, no issue. For inactive tab, interval throttled; at resume, now - nextStepTime huge. Reset. Need also cancel stale sounds? no future notes because no lookahead. Fine.
- Since schedule occurs ~2ms before sound, pattern toggle right at boundary can affect if before schedule; if after, sound may already be scheduled 2ms ahead. Practically immediate. To make absolutely live and still Web Audio, can schedule at `ctx.currentTime` without lookahead; Web Audio accepts current time and starts as soon as possible. Use `when=Math.max(now,nextStepTime)`; schedule source.start(when). This can work. Gain `setValueAtTime` at when. It may glitch slightly but okay. Then no sounds are queued in future >0ms. Could schedule at `now + 0.001` to avoid immediate automation weirdness. Use `when = Math.max(now + 0.001, nextStepTime)`. With interval condition `now + 0.004 >= nextStepTime`, if nextStepTime is up to 4ms future, `when=nextStepTime` (0-4ms ahead). Tiny. Use `Math.max(now + 0.001,nextStepTime)`. Perfect. Then Stop cancels all active voices; any source scheduled 1-4ms ahead may be stopped before start. Good.

But do we need use precise Web Audio scheduler? This is enough. We can call schedule every 5ms via setInterval; browsers may prohibit <4ms after nested, but 8ms is okay. Use 8ms and horizon 0.008. At 180 BPM step 83ms, timing jitter up to 8ms maybe noticeable but okay. Use 5ms; Chromium allows ~4ms. Use 10ms maybe. We can use `setTimeout` loop scheduled to wake near next step based on audio clock:
```
function armNextStep() {
 const delayMs = Math.max(0,(nextStepTime - ctx.currentTime)*1000 - 4);
 timerId = setTimeout(() => {
   scheduler(); armNextStep();
 }, delayMs);
}
```
But BPM change needs clear/reschedule timer to new delay. This is robust and fewer timer ticks. However duplicate timers risk; can guard. Simpler setInterval avoids rescheduling on BPM. We'll use interval.

Visual loop and audio queue:
```
function scheduleStep(idx, when) {
 visualQueue.push({step:idx,time:when});
 pattern.forEach((row,ri)=>{ if(row[idx]) trigger(ri,when); });
 lastStepTime=when;
}
```
`visualLoop` uses RAF; if browser tab hidden, queue grows but scheduler skips missed notes; fine. On stop clear.
- Need maybe playhead highlight current step after stop. `setCurrentStep(0)` and status "Stopped · Step 01". Starting again uses displayed pattern. No duplicate sequences due to `if(playing) return` and clear existing interval before start? We can assert:
```
if(schedulerId!==null) clearInterval(schedulerId);
if(rafId!==null) cancelAnimationFrame(rafId);
schedulerId=setInterval(...);
```
Even if state inconsistency. Play only if !playing. This prevents duplicates.
- BPM live update should not restart playback or create new intervals. `setBpm` only adjusts `nextStepTime`. Could add status event log maybe "Tempo 180 BPM" but status gets overwritten. We can show output.
- Could perhaps have visual metronome pulse via CSS `body.is-playing` etc. No need.
- Need maintain "Clear disables all steps." It should affect pattern array and all buttons/aria. It does not stop playback. Starting again uses currently displayed pattern.
- "Start with a simple audible pattern." Yes.
- "Unlock audio through a user gesture" maybe add a small `Audio: locked/running` indicator? Nice for verification. Could show status pill `#audioState` text "Audio ready after Play" initially. Play creates context and updates to "Audio running". Stop leaves running. Step or controls maybe create context. Could include. But not necessary. Might help browser inspect. Add a small `audio-chip` with text "Audio: not started". On Play click, update to "Audio: running". Could be useful to verify unlock. Need handle autoplay context state.
- To avoid external fonts, use system stack. No network.
- Could animate button on hit with `.hit` class? Current step highlight enough. Could pulse on row active. We can add short CSS transitions.
- Need avoid an issue with `DynamicsCompressorNode` connecting master and all voices; fine.
- Noise buffer: create once at ctx sampleRate, length maybe 1 second, fill with random. For each noise voice, use same AudioBuffer and `AudioBufferSourceNode`, with playbackRate 1 and start offset random to make hits vary:
```
source.start(when, Math.random()*0.7, duration); 
source.stop(when+duration);
```
`AudioBufferSourceNode.start(when, offset, duration)` third arg duration stops automatically; then no need `.stop`. But for tracking cancellation, could call `.stop(when+duration)` as well. Using offset/duration: start(when, offset, duration); onended at end. Need register. To vary each hit, random offset. For clap envelope 0.2s, noise length 0.25. For snare 0.22s. Good.
- Need account source stop cancellation before start with `start(when, offset, duration)` and then calling `stop(now)`: if now<when, it should cancel. Fine.
- For oscillator sources, create and call start(when), stop(when+duration). Need frequency automation:
```
osc.frequency.setValueAtTime(155, t);
osc.frequency.exponentialRampToValueAtTime(48, t+0.11);
osc.frequency.exponentialRampToValueAtTime(42,t+0.42);
gain.gain.setValueAtTime(0.0001,t);
gain.gain.exponentialRampToValueAtTime(0.95,t+0.005);
gain.gain.exponentialRampToValueAtTime(0.0001,t+0.42);
osc.connect(gain).connect(masterGain);
```
Need avoid exponentialRamp from 0; use 0.0001.
- Kick click perhaps oscillator square at 800Hz with 0.01s envelope, but unnecessary. Distinct.
- Snare:
```
const noise = createNoise(t, 0.22);
const hp=ctx.createBiquadFilter(); hp.type='highpass'; hp.frequency=1200;
const bp maybe...
const noiseGain=ctx.createGain(); envelope 0.0001 -> .55 in .002 -> .0001 in .18
noise -> hp -> noiseGain -> master
const body=ctx.createOscillator(); body.type='triangle'; body.frequency=185; ...
gain .25 decay .12
```
- Hihat:
```
noise->highpass 7000 -> bandpass 10000 Q .8 -> gain envelope .35 -> .0001 .055
```
Maybe closed hat too short. Add metallic oscillator? Requirement distinct from snare/clap; highpass noise is distinct. Could use six square oscillators through highpass but more complex. Fine.
- Clap:
```
noise -> bandpass (freq 1300,Q .7) -> gain
gain automation pulses at t, t+.012, t+.024 with quick attack and exponential decay. final tail at t+.038 to t+.2.
```
Need ensure automation events don't conflict with exponential ramps:
```
g.gain.setValueAtTime(0.0001, t);
function burst(offset, level, decay) {
 g.gain.setValueAtTime(0.0001,t+offset);
 g.gain.linearRampToValueAtTime(level,t+offset+0.001);
 g.gain.exponentialRampToValueAtTime(0.0001,t+offset+decay);
}
burst(0,.5,.012)
burst(.014,.45,.012)
burst(.028,.4,.012)
g.gain.setValueAtTime(.32,t+.042)
g.gain.exponentialRampToValueAtTime(.0001,t+.22)
```
There might be overlap: second burst starts at .014, first decay ends .012, okay. Third at .028, second ends .026. Final at .042, third ends .040. Good.
- Need level management; master gain .7, compressor. Ensure no clipping.
- Register voices:
```
function finishVoice(sources,nodes) {
 let remaining=sources.length;
 const voice={...};
 activeVoices.add(voice);
 const done=()=> {
   remaining -=1;
   if(remaining===0) {
     nodes.forEach(n=>{try{n.disconnect()}catch{}});
     activeVoices.delete(voice);
   }
 };
 sources.forEach(s=>{s.onended=done;});
}
function launch(kind,t) {
  const sources=[], nodes=[];
  ...
  sources.forEach(s=>{...start...});
  register...
}
```
But need call start/stop after setting onended and adding active voice. Could have function `startVoice(sources,nodes,start,stop,offset,duration)`:
```
const voice={sources,nodes,ended:0};
activeVoices.add(voice);
for source:
 source.onended=...;
 if(noise) source.start(when, randomOffset, duration); else {source.start(when); source.stop(when+duration)}
```
If noise source with duration argument automatically ends; no extra stop. To ensure cancellation we can call stop(when+duration) too, but `start(when, offset, duration)` already stops. Calling stop might be redundant but okay; latest stop. Might throw if stop time before start? no.
```
function startSources(voice, when, duration, isNoise) { ...}
```
Could just define helper `voice(sources, nodes, startFn, endFn)` and call.
Simpler:
```
function prepareVoice(nodes, sources) { ... }
function startVoice(voice, when, duration, noiseOffset) {
 activeVoices.add(voice);
 let ended=0;
 sources.forEach(s => {
   s.onended = () => {...};
   if (s instanceof AudioBufferSourceNode) ... // instanceof may fail cross realm? fine
   else ...
 });
}
```
Need know which are noise. Could mark `s._noiseBuffer=true` custom property? Add object `{node, offset}`. Better:
```
function makeVoice(nodes, sourceSpecs) {
 const voice={nodes,sources:sourceSpecs.map(s=>s.node),count:...}
 activeVoices.add(voice);
 ...
 sourceSpecs.forEach(({node,offset})=>{
   if(offset !== undefined) node.start(when,offset,duration);
   else {node.start(when); node.stop(when+duration);}
 })
}
```
Need pass `when`,`duration` to function.

Let's outline JS:
```
(() => {
'use strict';
const TRACKS=[{id:'kick',label:'Kick',desc:'...'},...];
const INITIAL=[...];
const pattern = INITIAL.map(row=>[...row]); // booleans
let audioCtx=null, master=null, noiseBuffer=null;
let bpm=120, playing=false, starting=false;
let schedulerId=null, rafId=null, currentStep=0, nextStep=0, nextStepTime=0, lastStepTime=null;
let visualQueue=[];
const activeVoices=new Set();
const cells = Array.from({length:4},()=>Array(16));
const markerEls=new Array(16);
...
buildGrid()
...
function ensureAudio() { ... }
```
Need perhaps use async/await. Browser environment likely Chromium supporting. Fine.

Build grid:
```
const ruler = document.getElementById('ruler');
ruler.innerHTML = '<div class="ruler-label">STEP</div>';
for i 0..15:
  const m=document.createElement('div'); m.className='beat-marker'+(i%4===0?' downbeat':''); m.dataset.step=i; m.textContent=['1','e','&','a'][i%4] maybe repeated; m.title=`Step ${i+1}`;
```
If showing subdivision letters, quarter beat starts show numbers 1..4:
```
const labels=['1','e','&','a'];
m.textContent = i%4===0 ? String(i/4+1) : labels[i%4];
```
4 beats repeated; nice.
- Create track:
```
const row=document.createElement('div'); row.className=`track track-${track.id}`; row.dataset.track=...
const label=...
for i:
 button=document.createElement('button');
 button.type='button';
 button.className='step'+(on?' on':'')+(i%4===0?' downbeat':'');
 button.dataset.row=r; button.dataset.step=i;
 button.setAttribute('aria-pressed',on);
 button.setAttribute('aria-label',`${label} step ${i+1}`);
 button.innerHTML=`<span>${i+1}</span>`;
 button.addEventListener('click',()=>toggleStep(r,i));
 cells[r][i]=button;
```
Use `document.addEventListener('pointerdown', unlockOnGesture,{once:true})` to create context on any pointerdown. But careful: browser tool's `click` may dispatch pointerdown; yes. `unlockOnGesture` calls `ensureAudio()` asynchronously. It creates context and `resume()` from user gesture. Then Play calls ensure again. Good. But when clicking Stop/Clear etc., audio will unlock too. It's okay. Might also try to resume on keyboard? Add `keydown` once perhaps. Could just call `ensureAudio()` in Play and toggle step click. To be safe:
```
document.addEventListener('pointerdown', () => { ensureAudio(); }, {once:true});
document.addEventListener('keydown', () => { ensureAudio(); }, {once:true, capture:true});
```
This could create AudioContext when any key pressed; still user gesture. Good. But asynchronous `resume()` call inside event handler is valid because called synchronously before first await. ensureAudio function calls `ctx.resume()` then returns Promise. Fine.
- Need avoid autoplay warning console. Creating context on pointerdown is allowed. `ensureAudio` might return rejected Promise unhandled on generic pointerdown. Add `.catch(()=>{})` when called from listener. For Play, handle catch. Could avoid global unlock and rely on Play. Requirement only unlock through gesture. Let's rely on Play plus step click perhaps:
```
async function ensureAudio() { ... }
playButton.addEventListener('click', async () => { await start(); });
grid.addEventListener('click', e=> { ... ensureAudio().catch(()=>{}); ...});
```
Maybe no need to create audio on step clicks. Play is the gesture that starts audio. Good. Could add `pointerdown` on Play itself. But click handler asynchronous awaiting `ctx.resume()` must ensure `ctx.resume()` called directly within gesture before await; yes:
```
async function unlockAudio() {
 if(!audioCtx){...}
 if(audioCtx.state!=='running') await audioCtx.resume();
}
```
`resume()` called before await. Good.
- Some browsers need `audioCtx.resume()` on a click event and may remain suspended if called from async function after state check? State check sync, resume sync. Fine.
- `start()`:
```
async function handlePlay() {
 if(playing || starting) return;
 starting=true; playBtn.disabled=true;
 try {
   await unlockAudio();
   startPlayback();
 } catch(err) { setAudioState('Audio unavailable'); console.warn(...) }
 finally{starting=false; playBtn.disabled=false;}
}
```
No console errors ideally.
- `unlockAudio` creates noiseBuffer:
```
const AudioCtx = window.AudioContext || window.webkitAudioContext;
if(!AudioCtx) throw new Error...
audioCtx = new AudioCtx();
masterGain=audioCtx.createGain(); masterGain.gain.value=.72;
const comp=audioCtx.createDynamicsCompressor();
...
masterGain.connect(comp); comp.connect(audioCtx.destination);
noiseBuffer=createNoiseBuffer();
```
Actually audio master chain: voices -> `masterGain` -> compressor -> destination. Fine.
`createNoiseBuffer` 2 seconds maybe. 1 second enough; random offset up to 0.7 and duration .25. Need no clipping. Use Math.random()*2-1. Could apply slight envelope? Voice gain handles.
- Audio state indicator:
```
function updateAudioStatus(){
 audioChip.textContent= audioCtx ? `Audio: ${audioCtx.state}` : 'Audio: click Play to unlock';
 audioChip.classList.toggle('live', audioCtx?.state==='running');
}
```
Call on unlock and statechange. Add `audioCtx.onstatechange=updateAudioStatus`. Browser console maybe no issue.
- `createVoice`:
```
function registerVoice(sources, nodes, when, duration, offsets=[]) {
 const voice={sources,nodes,remaining:sources.length};
 activeVoices.add(voice);
 const cleanup=()=> {
   voice.remaining -=1;
   if(voice.remaining<=0) {
     activeVoices.delete(voice);
     for(const n of nodes) try{n.disconnect()}catch{}
   }
 };
 sources.forEach((source,idx)=>{
   source.onended=cleanup;
   if(source instanceof AudioBufferSourceNode) {
      const offset=Math.random()*Math.max(0,noiseBuffer.duration-duration-.01);
      source.start(when,offset,duration);
   } else {
      source.start(when);
      source.stop(when+duration);
   }
 });
}
```
Potential issue: `AudioBufferSourceNode` may not be global in Safari? likely. Can mark source as noise via `source.dataset` impossible on AudioNode. Could check `source.buffer !== undefined`:
```
if ('buffer' in source && source.buffer) ...
```
Oscillator nodes don't have buffer. Use `source.buffer === noiseBuffer`. Fine.
- For each voice creation, define node connections. Need include all source and processing nodes in `nodes` for disconnect:
```
const nodes=[osc,gain];
...
registerVoice([osc], nodes, t, .45)
```
- Need maybe use `GainNode.gain.cancelScheduledValues(t)`? New gain, no need.
- `triggerDrum(trackId,t)` switch. Need ultimately pass row index. Use constants.

Detailed synthesis code:

```
function newGain() { return audioCtx.createGain(); }
function makeNoiseSource(duration) {
 const src=audioCtx.createBufferSource();
 src.buffer=noiseBuffer;
 return src;
}
```
`registerVoice` chooses random offset. Need buffer source start with duration. For `source.start(when, offset, duration)`, if offset+duration > buffer.duration (1s) and duration <= .25; offset random up to .7, safe. Could compute `Math.random()* (noiseBuffer.duration-duration)`, e.g. .75. Good.
Could set buffer source playbackRate maybe 0.9+random*.2; but not needed. To vary, `src.playbackRate.value=0.9+Math.random()*.2`; duration then may not cover full envelope perhaps. Keep 1.

Kick:
```
function kick(t) {
 const osc=ctx.createOscillator(), gain=ctx.createGain();
 osc.type='sine';
 osc.frequency.setValueAtTime(150,t);
 osc.frequency.exponentialRampToValueAtTime(52,t+.09);
 osc.frequency.exponentialRampToValueAtTime(42,t+.32);
 gain.gain.setValueAtTime(.0001,t);
 gain.gain.exponentialRampToValueAtTime(1.0,t+.004);
 gain.gain.exponentialRampToValueAtTime(.0001,t+.42);
 osc.connect(gain); gain.connect(masterGain);
 startVoice([osc],[osc,gain],t,.43);
}
```
Could add click:
```
const click=osc square? would be second source and gain. Not needed.
```
Snare:
```
const noise=createBufferSource, hp, bp?, ngain
hp.type='highpass'; hp.frequency.value=1300;
ngain envelope .6 decay .18
noise->hp->ngain->master
const body=osc triangle 185->120; bgain .28 decay .1
...
startVoice([noise,body],[...],t,.22)
```
Need body oscillator stop at .22 too, though its gain decays; fine. registerVoice passes same duration .22 for all. Noise source start when with duration .22; body start/stop .22. Great.
- Hi-hat:
```
noise->highpass 6500->bandpass 9500 Q .7->gain
gain .0001 -> .42 at +.001 -> .0001 at +.055
startVoice([noise],[...],t,.065)
```
Maybe add metallic oscillator partials with square waves to sound more hi-hat. Could have 3 oscillators at 4100, 6200, 8100 through gain; high frequencies maybe harsh. But requirement distinct percussion sounds from oscillators/noise; kick uses oscillator, others noise. Fine.
- Clap:
```
noise->bandpass 1200 Q .8 -> gain
envelope as above
startVoice([noise],[...],t,.24)
```
Need `exponentialRampToValueAtTime` after `linearRamp` with 0.0001 min. Good.
- Perhaps add slight stereo? No need.
- Master compressor settings:
```
comp.threshold.value=-10; comp.knee.value=10; comp.ratio.value=4; comp.attack.value=.003; comp.release.value=.15;
```
- `cancelVoices`:
```
function cancelVoices() {
 if(!audioCtx)return;
 const now=audioCtx.currentTime;
 for(const voice of activeVoices) {
  for(const s of voice.sources){ try{s.stop(now)}catch{} }
  for(const n of voice.nodes){ try{n.disconnect()}catch{} }
 }
 activeVoices.clear();
}
```
Potential problem: calling `s.stop(now)` on a source already scheduled with `start(when, offset,duration)` and `when > now` may throw `InvalidStateError`? Catch. If it throws, disconnecting nodes prevents sound. Good.
- On Stop, perhaps ramp master gain down/up to silence tails? Since disconnect voices already, no need. But if activeVoices cleanup mistakenly removed voice from set due to one source ended while another still active? registerVoice only removes when all sources ended; good.
- On Stop, activeVoices includes voice tails; disconnect all. Great.
- On Play after Stop, activeVoices clear; no duplicate.
- On Clear while playing, no active future notes because no lookahead. Good.
- On Toggle while playing, no duplicate sequence; just pattern array. Need maybe update `aria-pressed`.
- Need ensure "Starting again uses currently displayed pattern": scheduler reads pattern at each step; no cached copy. Good.
- Need BPM control from 60-180: clamp inputs; range and number both min/max. On `input` range updates live. Number input `input` could be temporarily empty; handler only if value !== ''; but if user types "1" it clamps to 60 and immediately changes field, making typing 180 hard. Could use `change` and `blur` for number, not `input`. But browser `type` may trigger input then change on blur. We'll add `change` and `keydown Enter` triggers blur. Could also use range programmatically. Use:
```
bpmNumber.addEventListener('change',()=>setBpm(bpmNumber.value));
bpmNumber.addEventListener('blur',...);
```
Maybe pressing Enter doesn't cause change in some cases; add:
```
bpmNumber.addEventListener('keydown',e=>{if(e.key==='Enter'){setBpm(bpmNumber.value); bpmNumber.blur();}});
```
This is okay. Range live.
- Could add BPM +/- buttons? No need.
- Need ensure `setBpm` called from range while playing adjusts next step but not create duplicate interval:
```
function setBpm(value) {
 const n = Math.round(Number(value));
 if(!Number.isFinite(n)) return;
 bpm = clamp(...);
 ...
 if(playing && audioCtx && lastStepTime !== null) {
  const desired=lastStepTime+stepSeconds();
  const now=audioCtx.currentTime;
  nextStepTime=Math.max(now+0.002,desired);
 }
 refreshStatus();
}
```
Potential issue if new duration is slower and `desired` is after old `nextStepTime`, fine. If faster and desired < `now`, set now+.002. Then the interval may not fire until up to 5ms later. Fine.
But what if BPM changes multiple times after last step: desired recalculates correctly. Good.
What if BPM changes while a step is scheduled 2ms ahead but not yet audible? lastStepTime refers to previous step, desired might be now+some; nextStepTime overwritten, but pending source/visual already scheduled. It will sound and highlight in 2ms; then next step based on desired maybe could be before that pending step if new duration fast? Let's examine:
- Suppose step k scheduled at when=T+0.002, lastStepTime currently set to T+0.002. Wait we set lastStepTime=when at scheduling, even though future by 2ms. `nextStepTime=when+dur`. If user changes BPM immediately after scheduling before when, desired = when + newDur, which is > when. So next step after pending, okay. If newDur very small (83ms), still > pending. Good. If desired clamp now+.002 (could equal or be slightly before pending) only if when+newDur <= now, impossible since when>now and newDur>0. So fine.
- Actually lastStepTime on Play is null until first step, then set to first schedule time. Good.
- Need update `nextStepIndex` when no note scheduled? On BPM change we don't change index. Fine.
- At scheduler:
```
function schedulerTick() {
 if(!playing || !audioCtx) return;
 const now=audioCtx.currentTime;
 if (now > nextStepTime + 0.08) {
   // timer stalled; skip ahead gracefully without burst
   nextStepTime = now + 0.003;
 }
 if(now + 0.006 >= nextStepTime) {
   const when=Math.max(now+0.001,nextStepTime);
   const idx=nextStepIndex;
   fireStep(idx,when);
   visualQueue.push({step:idx,time:when});
   lastStepTime=when;
   nextStepTime=when+stepSeconds();
   nextStepIndex=(nextStepIndex+1)%16;
 }
}
```
Need if `now > nextStepTime +0.08` and we set nextStepTime=now+.003, then condition `now+.006>=now+.003` true, fires immediately. Good. This means after tab stall a step fires immediately; okay. We could skip many notes and continue sequence at same index. Fine.
- `fireStep`:
```
for r 0..3 if(pattern[r][idx]) triggerDrum(r,when)
```
- `visualLoop`:
```
function visualLoop(){
 if(!playing)return;
 const now=audioCtx ? audioCtx.currentTime : 0;
 let nextVisual=null;
 while(visualQueue.length && visualQueue[0].time <= now + 0.002) {
  nextVisual=visualQueue.shift().step;
 }
 if(nextVisual!==null && nextVisual!==currentStep) setCurrentStep(nextVisual);
 rafId=requestAnimationFrame(visualLoop);
}
```
Queue times monotonic; yes.
- On Play call `setCurrentStep(0)` and `visualLoop()` starting with rAF. Need ensure `rafId` null:
```
if(rafId!==null)cancelAnimationFrame(rafId);
rafId=requestAnimationFrame(visualLoop);
```
Within visualLoop assign new id. But if start calls `visualLoop()` directly and it assigns rAF, okay. Perhaps simpler:
```
function startVisualLoop(){
 if(rafId!==null)return;
 const loop=()=>{...; rafId=requestAnimationFrame(loop);}
 rafId=requestAnimationFrame(loop);
}
```
Need cancel on stop. If `rafId` still non-null after callback executes? In loop, assigned next id each time. Good.
- `setCurrentStep` updates status and DOM. Need avoid `currentStep` maybe 0 initial and `setCurrentStep(0)` with force flag. Implement:
```
let paintedStep=-1;
function paintStep(step, force=false) {
 currentStep=step;
 if(!force && paintedStep===step) return;
 ...
 paintedStep=step;
 refreshStatus();
}
```
But status needs update on BPM change even if step same. Separate `refreshStatus()`.
```
function setCurrentStep(step){
 currentStep=step;
 if(prevPainted===step)return;
 if(prevPainted>=0) ...remove
 ...add
 prevPainted=step;
 refreshStatus();
}
```
On init call setCurrentStep(0); on stop call setCurrentStep(0) but paintedStep already maybe other; if it's 0 no DOM change but status refresh needed. Call refreshStatus directly after.
- Add `grid.dataset.currentStep = String(currentStep+1)` maybe easier inspect. Use 1-based? Test might expect 0? Could use both:
```
seq.dataset.currentStep=String(currentStep); // 0-based
seq.dataset.currentStepDisplay=String(currentStep+1);
seq.dataset.playing = playing?'true':'false';
seq.dataset.bpm = String(bpm);
```
Status text includes "Step 3 / 16". This is checkable. Add hidden `<span id="testReadout">`? Not needed, dataset accessible via inspect perhaps.
- `updateStatus`:
```
statusText.textContent = `${playing?'Playing':'Stopped'} · step ${String(currentStep+1).padStart(2,'0')}/16 · ${bpm} BPM`;
```
Initial "Ready" perhaps. After Stop "Stopped". Tests might want stop state. Use state variable.
```
let playbackLabel = 'Ready';
```
At Play "Playing"; stop "Stopped". Clear doesn't change. Use status pill.
- Maybe show live audio state second line.
- Need support keyboard toggles: native buttons do. Space/Enter triggers click; good.
- Need Play button disabled while starting only, not while playing. Stop and Clear remain.
- Need maybe handle Play when context resume fails; show status. Fine.
- Need perhaps no warnings from AudioContext on page reload. We don't create until gesture, fine.
- Need include `<meta name=viewport>`.
- CSS style should be sophisticated. Need keep enough time for browser checks.

Let's write the file. We can use write with full content. Need ensure no syntax errors. Let's carefully compose.

Potential meta: no external resources; CSS gradient/system fonts, inline SVG? Could use Unicode icons. No external assets. Fine.

CSS specifics:
```
:root { color-scheme: dark; ... }
*{box-sizing:border-box}
body{min-height:100vh; margin:0; background: radial-gradient(...), #080c14; ...}
body::before maybe grid pattern with linear-gradient; no network.
.app { width:min(1120px,calc(100% - 40px)); margin:0 auto; padding:42px 0 50px;}
header etc.
.panel {background:rgba...; border...; border-radius:24px; box-shadow...;}
.transport {display:grid; grid-template-columns: minmax(300px,auto) minmax(280px,1fr) auto; gap...}
```
At 1200 width, app ~1120, transport columns 350+400+250 =1000. Good. On narrow use media query.
- Play button accent green gradient, Stop blue/dark, Clear outline.
- status chip maybe grid column 3.
- BPM number input styled.
- sequencer `overflow-x:auto;` maybe panel wrapper.
```
.sequence-scroll { overflow-x:auto; padding-bottom:8px; }
.sequencer-grid { min-width:900px; display:grid; gap:8px; }
.ruler,.track { display:grid; grid-template-columns:132px repeat(16,minmax(34px,1fr)); gap:6px; align-items:center;}
```
At min-width 900: 132+16*34+16*6=772; actually min 900 leaves buttons ~41px. Good. At app width ~1080, buttons ~50px. Nice.
- `.step {width:100%; aspect-ratio:1; min-height:38px; border-radius:10px; ...}`. Buttons could be 50x50. Four rows + ruler ~250px. Fine.
- `.step.on` track accent:
```
.track-kick { --accent:#ff8a4c; --on:#ff7940; --soft:rgba(...);}
...
.step.on { background:linear-gradient(160deg,var(--on),var(--accent-dark)); ...}
```
Need define `--accent-dark`. Could just use `background: var(--on); box-shadow: inset 0 -8px 18px rgba(0,0,0,.25), 0 0 18px var(--glow);`. Define each `--glow`.
```
.track-kick {--on:#ff7a45;--glow:rgba(255,122,69,.36);}
```
- `.step.is-current`: outline 2px solid #f8fafc; outline-offset:2px; transform:translateY(-1px); maybe box-shadow plus glow. If we set box-shadow in `.on`, `.is-current` override could lose; use `outline` and `filter:brightness(1.15)`. Add `::after` perhaps small top bar. Use:
```
.step.is-current { outline:2px solid rgba(255,255,255,.95); outline-offset:2px; box-shadow:0 0 0 4px rgba(96,165,250,.16),0 0 18px rgba(...); }
.step.is-current.on { box-shadow: inset..., 0 0 0 4px..., 0 0 22px var(--glow);}
```
- Marker `.is-current` similarly background white, color dark.
- `.step.downbeat:not(.on)` background slightly lighter and border-left accent. But use `border-left:3px solid #536079`? Since border affects sizing maybe box-sizing handles.
- `.track-label` with dot and text, small. Distinct. Need labels visible.

HTML:
```
<main class=app>
<header class=hero>...
<div class=meter-badge>4/4 · sixteenth notes</div>
...
<section class=transport-panel>
...
```
Need status maybe at bottom row. Could use grid-template areas. Simpler:
```
<div class=controls>
 <div class=button-group>...</div>
 <div class=tempo-control>...</div>
 <div class=playback-status>...</div>
</div>
```
Flex wrap.
```
.controls {display:grid; grid-template-columns:auto minmax(260px,1fr) minmax(220px,auto); gap:24px; align-items:center;}
```
At 1200, okay. `@media(max-width:900px){.controls{grid-template-columns:1fr}}`.

Footer instruction text maybe:
```
<p class=hint>Play unlocks audio. Changes take effect on the next sixteenth note.</p>
```
Good.

Need maybe number input `inputmode=numeric`.

Status data:
```
<div id=status class=status role=status aria-live=polite>
 <span class=status-dot></span>
 <span id=statusText>Ready · step 01/16 · 120 BPM</span>
</div>
<div id=audioState class=audio-state>Audio waits for Play</div>
```
Need not update aria-live every step (could spam screen readers); maybe status text step updates 8 times/sec at 180 bpm, potentially noisy. Set `aria-live="off"` or use polite. Not important. Use `aria-live="off"`. Tests likely use text. Could add `<span id=stepReadout>`. Fine.

Maybe visual playhead changes at 8 steps/sec (120 bpm), status too. Browser inspect catches.

Let's write.

Need inspect file perhaps syntax check with node? We can run maybe `node --check` on extracted script. Need browser initial output and console. Use browser reload then inspect/screenshot. Let's call parallel? browser actions might need sequential reload then inspect. Could call reload first.

Initial looks good. Need note status starts Ready step 01; first column outlined. Need console [] no errors. Need test toggle a step and start playback; check playhead advances and BPM change; stop/start pattern retained and playhead restarts. Need use browser actions. Need figure coordinate mapping. Screenshot 1200x800. Grid step centers:
ruler starts x ~188 first, then x244, 300, 355, 412,468,523,579,635,690,746,802,858,914,970,1026? Actually pad centers first x213, second x269, etc. Kick row y416; snare y471; hihat y528; clap y590. Buttons appear 50x50.

Play at x98 y253. Stop x200 y253. Clear x300 y253. BPM range from x370 to893 y258, center~630. Number input x828 y227.

Need toggle a step: maybe kick step 2 (x269,y416) initially off; click. Need verify via screenshot maybe step orange. Then Play. Then inspect status after a moment. Browser tool actions may have inherent delays. Need perhaps use `browser click` on step, then inspect DOM perhaps `aria-pressed` not in text. Screenshot can show color. Could use browser inspect maybe returns DOM summary with data attributes? It gives text, not full DOM. Perhaps status. Could use `browser screenshot` to visually verify. Need perhaps use browser click and screenshot. Let's perform click on kick step 2, then play. We can call sequential.

Hmm after clicking step 2 screenshot, kick step2 appears tinted dark blue maybe hover, not orange. Wait initial kick step2 off; click should turn orange. Screenshot shows step 2 dark blue with slight orange glow? Actually at x269 y416, background perhaps #263650? It has orange halo? Let's zoom perhaps read pixels via screenshot? browser screenshot attached; we could use tool screenshot with maybe no need. Need determine if click toggled. It might be hovered (browser cursor remains at coordinate), and `.step:hover` background #1c2b41; but `.step.on` should override? CSS order: `.step:hover` before `.step.on`, so `.step.on` later should override background. It appears perhaps dark because click missed button? Coordinates maybe x269 is second cell center; yes. But screenshot first cell center x213, second x269. Step 2 looks dark blue with thin orange maybe from neighboring cell glow. Could click be on a gap? Actually first cell from x181 to243, second from x244 to299. x269 within. Why no orange? Need inspect DOM or `aria-pressed`. Browser inspect maybe gives attributes? It returned text only. Could use `bash` to perhaps use a headless DOM script? Browser tool doesn't offer evaluate. But we can expose state in status/log maybe add `data-active-count` or update status on toggle temporarily. Could add global debug state to visible text? Better use browser screenshot with pixel inspection perhaps by taking screenshot and using python? We don't have direct file path for screenshot, but perhaps tool gives image attached not saved. Could use browser inspect action with maybe argument? It just returns DOM text. Could perhaps use `browser click` on selected element and use keyboard? Need conclusively verify pattern toggle. Could modify app to show active count in status/hint, or add a visible `data-on` attribute to button and browser inspect might include? "inspect" maybe returns DOM text only but perhaps includes relevant attributes if we ask? Tool schema only action no selector. Could check browser action `inspect` returns maybe larger info including HTML? Let's call inspect.

Now step 2 orange. The prior screenshot was likely transient during CSS transition (100ms) and after inspect rendered full. Good toggle works.

Need Play click and check status over time. Let's click Play at (98,253). Browser click may produce audio context but perhaps headless audio unavailable? Need console. Then inspect screenshots at intervals. Browser tool actions are sequential; each call likely has some delay. Could use `motion` action maybe captures frames over some time to see playhead. Need understand motion tool: "see screenshots or motion frames." Could call browser motion with maybe no params; likely returns frames. Let's click Play first.

Interesting DOM text says Playing step 02, screenshot says step 01. Timing mismatch likely screenshot taken slightly before DOM snapshot? Anyway playback started, audio running. Need check advanced grid. Use motion maybe. Let's call motion.

Great motion frames show playhead advancing step10, step15, wraps to step4, step9, at 120 BPM across 0.624s intervals (5 steps per 0.624s =125ms precisely). Pattern edit kick step2 on. Good. Need check BPM change responsiveness. Need set range to maybe 180 by clicking near right endpoint x890,y258. Need inspect status and perhaps motion frame rate. Could use number input type easier: click number input (x828,227), select all and type "180" then Enter. Browser tool action `type` maybe types into focused element. Need use key ctrl+a? `browser key` with text? Need understand key schema: action key, text perhaps key name. Could click number input then use key with text `"ControlOrMeta+A"`? Could use `browser type` with text "180" after click; input may append to 120 (`120180`) then `change` clamp to 180 anyway, but number field might show `120180` then blur clamps to 180. Could be okay. Better use range click at x885 to set ~178/180. Use browser click at x885 y258. Range min 60 max180 over x370..892, so x885 gives ~178. Could then inspect status ~176. Good. Need test BPM change impacts playhead rate. We can use motion frames before/after; but already checked 120. After change, use motion 1 second and see >8 steps (~12 at 180 BPM). Need also read status displays 178 BPM. Let's click range near right endpoint.

BPM change to 180 shown. Need check rate maybe motion frames catch. Call motion maybe one call.

Interesting motion frames at ~0,692,1344,2018ms show step 2,10,2,10 repeating at 180 BPM. At 180 BPM one full 16-step bar is 16*83.33ms=1.333s. At 692ms, 8.3 steps from 2 ->10, yes. At 1344ms, wraps to2, at 2018ms ->10. Good. So BPM controls rate. Also note first frame screenshot shows playhead step2 and status step02; white outline, pattern retained including toggled kick step2. Good.

Need check Stop resets playhead first step and retains pattern; then Play starts again at first step. Need click Stop at x200,y253. Then inspect/screenshot. Need maybe stop at a non-first step. Use browser click on Stop and check immediate DOM. Then Play again and maybe inspect. Also check future hits canceled? We can perhaps use audio context state or status; not directly audible. Could instrument console? No need maybe. Need ensure no duplicate sequence on restart. We can check playhead rate and status; maybe graphical. Need also test Clear maybe check all cells off. Requirement includes Clear, likely should verify. We can click Clear after stop and inspect screenshot; but then pattern retained test would be compromised if clear before start. We can test stop/start first, then clear. Need maybe re-enable? Clear is irrecoverable but no need after final checks. Could then reload to leave initial pattern? Browser state doesn't affect file. Fine. Need check clear disables all. Let's do Stop then inspect.

Stop screenshot: white outline first column, pattern retained, status stopped step01/180. Good. Need check no future hits after stop—could wait a bit via motion or inspect; status should stay step01 and no console errors. Browser motion after stop perhaps. Then play again starts step1. Let's call motion to ensure stopped stays first step (future hits canceled visually). Then Play and inspect maybe immediate step01/02. Could use click Play then screenshot. Need perhaps ensure duplicate sequences not created by BPM change. Motion at 180 showed 8 steps per 692ms, exactly one sequence. Good.

Let's call motion after stop maybe frames all step1.

Great. Need Play again and check starts from first step and pattern retained. Click Play maybe immediate screenshot shows step1 then after small delay step2. Need perhaps use browser click and then inspect. If click returns after ~? In prior Play returned step02 and screenshot step01 (race). Either okay; "restarts from first step" can be verified by `nextStepIndex=0` before first hit and status initial. Click Play and capture. To be more definitive, perhaps use motion immediately after click? Browser click may have 0ms screenshot showing step1. Let's call click.

Excellent. Need check Clear. Could stop first then Clear to verify all off. Stop then clear. Use parallel? Need sequential. Click Stop.

Weird screenshot shows playhead at step3 visually while DOM status says Stopped step01. Maybe screenshot was captured during click before stop applied? Actually white outline at first column AND marker 3 white? Wait screenshot: marker "3" white (step9 column) while first column cells outlined; perhaps visual queue/rAF had just processed step9 before stop; status DOM maybe after stop but screenshot from prior frame? There's a race in browser tool screenshot vs DOM snapshot perhaps. Need not worry. But could there be a bug that stop doesn't remove current marker from a previously queued step? Let's inspect carefully. `stopPlayback` calls `setCurrentStep(0)`, which removes `.is-current` from `paintedStep` and adds to 0. If paintedStep is step8 (marker 3), it should remove marker white. Screenshot shows first column cells outlined but marker 1 dark, marker3 white. That suggests `paintedStep` mismatch: perhaps visual queue processed a step but `setCurrentStep` wasn't called because `visibleStep === currentStep`? Let's reason.

Potential bug: `setCurrentStep(0)` called at startPlayback; `paintedStep=0`. At visual loop, when queue step0 arrives, `visibleStep=0` and `visibleStep !== currentStep` false, so no `setCurrentStep`, but currentStep already 0, painted 0. Fine. At step1, setCurrentStep(1): remove marker0 and cells0, add marker1/cells1; painted=1. Good. At stop while painted=8: remove marker8 and cells8, add marker0 and cells0; painted=0. Should show marker1 white and first col outlines. Screenshot shows marker3 white and first col outlines: maybe screenshot captured mid-transition between old highlight removal and new highlight addition? JS event handler executes synchronously, not paint mid-way; no.

Maybe screenshot's marker3 white is actually range or browser visual? The ruler marker at x694 (step9) is white; marker1 at x213 is dark. First column cells have white outline. This could indicate two current indicators because `paintedStep` had somehow been reset to 0 while marker8 remained. How could that happen? Let's review `setCurrentStep`:
```
if (paintedStep !== step) {
 if (paintedStep >=0) { markers[paintedStep].remove ... }
 ...
}
```
At stop, if paintedStep is -1? No.
Maybe this screenshot was from before stop due tool images being attached from prior motion frames? The tool output says Frame 1 +0ms and one image attached, likely current. Could be screenshot captured at click pointerdown but before click handler? DOM snapshot after handler. This would explain marker3 white and no first column outline? But screenshot shows first column outline, which was present before stop? At step9, first column should not be outlined. Hmm maybe white outline around first column is `.step.is-current` from stop, while ruler marker3 text white due CSS transition on background from previous state. `beat-marker` transition is 80ms; screenshot taken ~0ms after stop could catch mid-transition: marker1 is transitioning from white to dark (but appears dark), marker3 from dark to white (appears white) because of CSS transition timing? Removing `.is-current` from marker3 should transition background from white to dark; at t=0 it should still white. Adding `.is-current` to marker1 should transition from dark to white; at t=0 still dark. But CSS transitions can start at opposite times depending style recalc: likely exactly mid-transition at screenshot frame. The cells do not have background transition for outline (outline no transition), so first column outline applies instantly. So the screenshot is likely at immediate stop with marker transition mid-flight. After ~100ms, marker1 white and marker3 dark. The earlier stop motion frames showed marker1 white and all others dark. So fine.

Need click Clear and inspect.

Screenshot still shows pattern on despite click Clear. Could be CSS transition at t=0 after class removal (background transitions 100ms), so still colored. Need inspect after a moment maybe motion or screenshot. Browser screenshot called immediately may show state before transition. Use inspect after short delay perhaps `screenshot` action separate now.

Clear works. Need maybe reload to leave initial pattern? The file itself remains initial; browser state doesn't matter. Could reload to inspect final initial output again. Need perhaps check console after all: [] throughout. Great.

But let's consider potential hidden issues in code that might affect required behavior:
1. `color-mix(in srgb, ...)` might not be supported in some browser, but Chromium supports. If unsupported, border-color declaration invalid but background still works. Fine.
2. `registerVoice` checks `source.buffer === noiseBuffer`. For `OscillatorNode`, accessing `source.buffer` returns undefined; fine.
3. `activeVoices` cleanup: For snare, noise source started with duration .21, body oscillator stopped at .21. Both onended fire; remaining from 2 to 0; fine. If stopPlayback calls `source.stop(now)` on a source whose start is scheduled up to 1ms in future, then manually disconnect nodes and clear set. The source may still fire `onended` later but `voice` no longer in set; callback `finished` decrements and disconnects again; harmless.
4. `setBpm` while playing and `lastStepTime !== null`: If user changes BPM after Stop? playing false, no effect. Fine.
5. `setBpm` range input while playing: `nextStepTime` re-spaced from last step, but if desired < now+0.002, next step immediate. Fine.
6. If BPM changes multiple times right after a step, `nextStepTime` always from lastStepTime. Fine.
7. If BPM changes when `lastStepTime` is future by 1ms (pending step), desired = lastStepTime+newDur, so still after pending. Fine.
8. StartPlayback calls `schedulerTick()` immediately; nextStepTime = currentTime+0.035, horizon .006 means no note scheduled, but visual loop starts and first column highlighted. First note after 35ms. Good.
9. Stop cancels future hits: the only future hit is at most 1ms scheduled; cancelVoices calls stop(now), disconnect. Good.
10. Starting again uses current pattern: scheduler reads pattern each step. Good.
11. Editing steps while playing affects playback: schedule only ~1ms ahead; practically immediate. Could satisfy. If a toggle happens exactly after a step's fireStep but before its sound 1ms later, technically hit still sounds; negligible. No duplicate sequences.
12.
Clear doesn't stop playback. Good.
13. BPM control from 60 to 180: range + number clamp. Good.
14. Distinct percussion sounds synthesized via oscillators/noise/envelopes: yes.
15. Audio unlock through user gesture: Play click creates/resumes context. Good.
16. No external resources/network: all inline. Good.
17. One self-contained index.html. Good.

Potential issue: initial pattern arrays refer 0-based steps, and visual labels show 1,5,9,11,13 kick; snare 5,13; hihat odd numbers 1,3,...15; clap 13,16. This is a nice audible pattern.

Need perhaps run a JS syntax extraction check with node to be certain; browser already no console errors. Could use node? No need but can. Need maybe check file only index.html and no external references. `ls`, `grep` maybe. We can do quick:
```
ls -la
node -e extract script and new Function...
```
Need maybe use bash to confirm no external URLs. Not necessary but useful. Could run `grep -E "https?://|src=|href=" index.html`. Also initial reload after Clear to leave correct initial state in browser. We should perhaps reload to final state and inspect again; but no need. However addendum says "Run application in browser and inspect initial output and console. Use available browser tools for brief pass through representative checks. Fix clear problems and recheck affected behavior. Save final file ... report what checked and unverified." Need perhaps final browser reload to ensure final file and initial state. We have not edited after writing, so okay. Could reload and use screenshot/inspect once to ensure initial pattern again. Let's do maybe.

Good. Need maybe reload final to initial state and console. Let's do.

All good. Need final response concise, mention what actually checked and unverified. Must not overclaim audio audible verification; browser tool likely headless may not expose sound. We did check Audio running and no console errors, but could not perceptually verify audio output. Need mention unverified: actual audible output/timbre and cancellation of in-flight audio could not be listened to directly; but code stops/disconnects sources. Also perhaps exact audio timing under background tab throttling and all BPM values 60-180 not tested; we tested 120 and 180 and range min/max. Need be honest. Also mention no external resources. Need report path clearly. Could say:

"Created `/tmp/job-o0a5nW/index.html` (single self-contained file)."

Checks:
- Initial render with four rows ×16 pads, initial pattern, first-step playhead, console empty.
- Toggled Kick step 2; started playback; unlocked audio state "running"; motion frames showed playhead advance/wrap at 120 BPM.
- Clicked range to 180; status updated and faster advance/wrap; no duplicate playhead sequence.
- Stopped: status stayed step01 across ~1.9s motion frames, pattern retained. Restart: step01 and retained pattern.
- Clear: all pads dark.
- Syntax check and external reference scan clean, final reload no console errors.
Unverified:
- Could not listen to/measure actual synthesized audio; only verified AudioContext running and code path no errors. Exact timing under tab throttling / every BPM value / keyboard interactions not exhaustively tested.

Need maybe say "audible" not verified. Fine. Ensure no mention "no duplicate sequence" beyond visual maybe. We can say "motion frames showed one playhead sequence rather than duplicated highlights." Good.

Let's final with brief.