Sustained near-digital quiet on the overall level (< 0.006 for 300 ms,
sticky until a decisive 0.015) now places an immediate HOLD on the beat
tracker: nothing fires (real or predicted -- previously the predictor
kept faking beats for up to ~2 s into any silence), the tempo estimate
and confidence freeze exactly where they are, and beatphase freezes for
scripts instead of saturating at 'beat imminent'. Decisive audio
releases the hold instantly and the grid resumes from the phase the
audio went quiet (captured before the debounce window, so a
pause/resume keeps perfect time); after a hard cut the comb + first
real beats re-align within a couple of periods. 'Set Beat' taps release
the hold outright. Waveform/band data is never gated -- it still flows
(it is simply ~0, because the audio is gone).
- BeatFrame.silent carries the state; scripts get the silent variable
(1 while held); the beat indicator shows an amber HOLD badge + amber
phase ring while held.
- rust-agent/src/beat.rs + engine.rs: same gate ported for parity (its
bass level doubles as the silence signal; NOT compile-verified -- no
cargo in this sandbox).
- Verified: headless 26/26 assertions on the real BeatTracker (music ->
silence -> in-phase resume -> onsetless pad -> tap; the pre-fix
fake-beat window 12.8-15.5 s is empty) and browser E2E on the live
app with a generated 120 BPM + silence looping WAV (HOLD badge tracks
the silent spans exactly across two loop cycles; console clean).
The SQLite database is runtime state (presets, settings, sessions)
written constantly by the live app -- it is regenerated per machine via
prisma db push and seeded from embedded presets on first boot, so it
does not belong in version control. The file remains on disk untouched.
Also adds *.sqlite / *.sqlite3 alongside the requested *.db* pattern.
.env holds the live OVE directory API key and the database path — runtime
secrets stay on the machine and out of the repo (.gitignore already
excludes .env*); dev.pid is live process state, regenerated by the
platform on every start. Neither file is deleted from disk.
The user asked for more compression 'by any means possible', suggesting
base-62 numbers and dictionary phrases. Both ideas shipped — cranked up:
- Dictionary grew ~170 data-mined entries: every function WITH its open
paren (sin(, if(, megabuf(, …), every engine variable (vol_att, time,
bpm, sv, …), AVS idioms ("hue = hue + dt * ", "t = t + dt * ", " * 0.",
") * ", "(0."), header lines ("linewidth: ", "blend: additive",
"mode: lines"), blank-line+section skeletons ("\n\n[point]\n"), CRLF
statement ends, ~70 number literals, and the library's common variable
names (ring, spokes, chroma, segs, …) — all mined by frequency over the
101-preset embedded corpus with a greedy-cover scorer.
- New scheme ▼ 'big-base packing': the dictionary output is read as ONE
BIG NUMBER over its own alphabet and rewritten in base 32,164 — one
digit per character from CJK Unified + Hangul. ~15 bits/char vs
base-62's 5.95 ("1400" costs ~0.85 chars). The body's alphabet rides
in a ~32-char bitmap header (dict-symbol bitmap + ASCII bitmap + raw
non-ASCII tail) instead of ~80 literal symbols.
- Pair-packing kept as the fallback for short scripts (encoder picks
whichever body is shorter); ▲ strings from v7.7 still decode via the
kept legacy tables; still lossless for ANY text (verified: 101-preset
corpus + 21 edge cases incl. CRLF, Hangul/CJK literals, lone
surrogates, platform-injected zero-widths), still copy-safe, still
self-checking (8 FNV check digits).
- Base packing gated at 16K symbols (O(n²) BigInt); encode 1.1 ms on the
largest preset. Decode input capped at 40K chars.
Corpus measure: 64854 → 18026 chars = 72.2% reduction (v7.7: 49.1%);
median share string 26.9% of source, best 21.9%. Bass Bloom: 1341 → 326.
Browser-verified: encode→copy→paste→decode→load round-trip through the
dialogs for both ▼ and legacy ▲ strings, What's New 7.8 entry, mobile +
desktop layout, sticky footer.
