Circuit Atlas · HUSH M4 · Rev 2027.4 draft · Simulation
E Browser app, DJ tools, sessions and offline (simulation)
Checks of the browser app on synthetic test signals. Not hardware measurements.
IN DEVELOPMENT · REV 2027.4 (DRAFT) · DESIGN TARGETS, NOT MEASUREMENTS
HUSH M4 is in development. This draft is published on zakkhutoretsky.com; it has no price and no ordering. Figures marked design target are goals for the finished product. Figures marked calculated come from the published formulas. No value on these pages was measured on a built unit. Interviews are cited as the design brief, not as an endorsement.
See this control Play the browser app Track decks on the playable panel
E Browser app: DJ tools, sessions and offline (simulation)
These are checks of the browser app on synthetic test signals made for the test. They are not measurements of the analogue mixer, they use no real music, and they say nothing about how the app sounds. The app runs only in the user’s browser; nothing is uploaded.
What it adds to the browser model
- Install and offline. A web app manifest and a service worker limited to /mixer. After one online visit the page, scripts, fonts and images of /mixer load without a network. The other pages of the site, the documents and the fan room are not cached by it. The cache is versioned and older versions are removed when the worker updates.
- Saved sessions. The mixer, EQ, FX, hi-fi and deck settings are kept in the browser’s localStorage and restored on reload, can be saved under a name, and can be exported and imported as JSON (settings and cue points only, no audio). Tracks are stored only if the user ticks the opt-in box, then in the browser’s IndexedDB, and can be removed again.
- Per-deck tools. Tempo detection, tap tempo, a pitch fader of ±8% or ±16%, nudge, loops of 1/4 to 16 bars on the detected beat grid, four hot cues and a sync option that is off until pressed. Pitch and tempo move together, like a turntable: key lock (changing tempo without changing pitch) is not available in this version.
- Library, MIDI, keys. A searchable list of the tracks loaded in the tab. Web MIDI learn and map with save and load, where the browser has Web MIDI (not Safari). Keyboard shortcuts with a help sheet, touch gestures, and a first-run tour that can be skipped.
The hardware design is unchanged. Appendix C records that DVS1 pitches records on the turntable (q24) and that the M4 hardware has no tempo, BPM or sync function. The app’s tempo tools are an addition of the software model, not something DVS1 asked for, and the sync option is off by default.
Tempo detection on synthetic tracks
| Track (generated) | True BPM | Read BPM | Error (BPM) | First beat error (ms) |
|---|---|---|---|---|
| click 100 | 100.0 | 100.000 | 0.000 | 0.250 |
| click 128 | 128.0 | 128.000 | 0.000 | 0.270 |
| click 140 | 140.0 | 140.000 | 0.000 | 0.280 |
| kick 174 | 174.0 | 174.000 | 0.000 | 0.680 |
| kick 124 | 124.0 | 124.000 | 0.000 | 0.660 |
Run in Chromium through the real app. In addition, 80 synthetic tracks (click and kick plus hat, 80 to 180 BPM, 44.1 and 48 kHz, 40 s) were run through the same detector in Node: 78 read within 0.05 BPM, worst error 0.01 BPM, worst first-beat error 1.67 ms. The misses are octave errors: kick 80 read as 160. The detector looks at the first 150 s of a track, searches 70 to 190 BPM and assumes a steady tempo; real recordings with swing, tempo drift or no clear kick were not tested.
Loops, hot cues, pitch and sync
| Check | Condition | Result |
|---|---|---|
| Loop sample accuracy | A 2.0 s loop on a ramp track, rendered offline at rate 1.0, three start positions | Worst error 0.007 samples over 265 377 samples |
| Hot cue jump | Cue stored as a whole sample, jump rendered offline | Worst error 0.013 samples; stored frame equals the frame at the press |
| Pitch +5% | Position read back after 20 000 output samples, offline | Worst error 0.007 samples |
| Tap tempo | Seven taps 500 ms apart, driven by a page timer | 119.37 BPM (120 expected); the error is the timer’s own jitter |
| Sync | Two playing decks, follower tempo matched to the leader and its beat phase aligned when sync is pressed; measured against the detected beat grids, so it is only as good as the detection | Tempo difference 0.0 BPM, beat offset -0.0 ms at the press, unchanged 2.5 s later |
| Interaction speed | Four decks playing, input to the next frame callback, 80 samples, headless Chromium with software graphics (a frame takes about 40 ms there) | Median 40 ms, 95th percentile 46 ms, worst 88 ms. The handlers themselves took 1.4 ms at the 95th percentile and never more than 4.4 ms. The browser’s own event timing, which waits for the next paint, reported up to 152 ms in this setup; in a side-by-side run of thirty clicks and slider moves with four decks playing, this page and the previous release both reported 104 ms at most |
Limits
- Live playback at a pitch other than 0% is positioned by the browser’s resampler; the sample-exact figures above are for rate 1.0 (loops, cues) and for the offline position check at +5%.
- The loop and cue figures are for an offline render of the same source node settings the decks use; the audio device and the browser’s scheduling add their own latency on a live deck, which was not measured.
- MIDI learn takes absolute controllers (knobs and pads). Relative encoders, pickup and 14-bit controls are not supported. It was tested with a scripted controller, not hardware.
- Only Chromium was tested. Safari has no Web MIDI; other browsers were not run.
- Interaction timing was measured on a build machine without a graphics card, so it says little about phones.