Releases: zamber/huemux
Release list
v0.0.4-alpha.4
v0.0.4-alpha.3
v0.0.2-alpha.38
HueMux v0.0.2-alpha.38 — Audio pickup controls, a stream debug log, and a live Android capture preview
Alpha. This release is about the capture side of the app: the audio
histogram now updates at a configurable rate instead of once a second,
there are real audio-pickup settings, the debug log no longer drowns in
per-stream noise, and on Android the capture preview and histogram are
finally driven by the actual stream instead of being blank.
The histogram is no longer stuck at 1 Hz
The audio histogram and capture readouts updated once a second, because they
rode the status push. A beat that comes and goes in a quarter of a second
barely moved a once-a-second bar.
There is now a separate debug push that runs at up to 30 times per second
(default 10, settable in Debug → "Debug data rate"). It carries the same
analysis the status push did, plus capture statistics, so the histogram has
something to bounce with. The UI also holds each bar's peak for a few frames
and decays it, so a drum hit stays visible instead of vanishing between
pushes.
Audio pickup settings
Two new settings under Advanced → Debug:
- Audio gain (default 2.0) boosts the captured audio before analysis. If
the histogram barely moves, raise it. It applies to the real analysis frame
— reactivity included — not just the display. - Audio floor (default 0) silences bands below a level, for hiding a
constant hum or hiss.
Stream debug data no longer swamps the app log
Per-stream telemetry — PCM summaries, analysis-frame stats, Android's capture
pipeline lines — now goes into a separate stream log ring. The app-event
log keeps the one-off events that a diagnostics report is actually read for,
and the report gained a stream stats section and a stream log section so
the stream telemetry is still there when you need it, just not in your way.
Android capture preview and histogram
On Android there was no capture preview at all: Kotlin captures and pushes
frames into the Go engine in-process, and the WebView never saw them. Now,
when you turn on Debug → "Stream echo to this device", the server sends a
downscaled copy of the live grid to every connected UI over the same WebSocket
every tab already uses. The Android WebView draws it as the capture preview,
with a luminance histogram strip along the bottom, and — in audio mode — the
same peak-held spectrum as the desktop page.
It is a resource-burn feature, so it is off by default and capped at 10 frames
per second. Desktop browser capture gets the same echo, which is harmless
redundancy.
Black cutoff default is now 0
The default black-cutoff level was 0.02 (a tiny amount of "this is black"
tolerance). It is now 0, and saved settings that still hold the old 0.02
default are migrated automatically. Any value you actually set is left alone.
What this does not do
It does not change how audio is captured — same sources, same analysis. The
gain/floor settings shape what the analysis hears, and the faster push makes
the histogram honest about it.
Full Changelog: v0.0.2-alpha.37...v0.0.2-alpha.38
v0.0.2-alpha.37
HueMux v0.0.2-alpha.37 — Screen capture works again, and Kotlin shows up in diagnostics
Alpha. If capture started failing on your device in alpha.36, this build
fixes it. It also makes the in-app diagnostics report say something useful
about Kotlin-side failures, which is why the regression survived in the
first place.
Capture is fixed
alpha.36 tried to start audio alongside the screen by passing a third argument
to the Android bridge:
no method startCapture
The Kotlin method takes two. Android's JavaScript bridge matches methods by
name and argument count, so the call failed before anything could start —
screen capture included, which is why your diagnostics showed the capture never
permitted.
The fix is simple and also a small simplification: on Android, internal audio
already rides the same MediaProjection as the screen. One consent dialog has
always yielded both streams, so there was never a flag to pass. The web UI now
says exactly that, and calls startCapture(areaId, id).
Kotlin failures now reach the diagnostics report
Until now, the report's "recent log" only contained what the Go core decided to
say. A Kotlin exception on the capture path — like the missing-method bridge
error — happened and died without a trace, so the report you got back could not
tell you what went wrong.
There is now a global error grab on the Android side. Kotlin errors and
warnings are routed into the same 800-line ring buffer the Go core logs into,
so the next diagnostics report you send will name the Kotlin failure. It is
rate-limited so a hot error loop cannot flood the ring.
A crash is the one failure mode with no trace at all — the process dies with
it. The app now writes the last uncaught exception to disk, and the next
report's host block includes a "last crash" line naming what died.
CI now tests the Kotlin side
The bridge mismatch shipped because nothing checked it: CI ran Go tests, and
the bridge surface lives entirely in Kotlin and JavaScript.
There is now a dedicated Kotlin test job that runs on every push and pull
request. It builds the AAR, compiles the app against it, and runs the unit
tests — including a bridge-contract test that parses every
@JavascriptInterface method and every call site in web/ and fails if a call
names a method with the wrong argument count. The exact regression that broke
alpha.36 would now fail CI in seconds.
What this does not do
It does not change how capture behaves — same one-dialog capture, same audio
path. If alpha.36 capture was working for you, this is a diagnostics and
pipeline release.
Full Changelog: v0.0.2-alpha.36...v0.0.2-alpha.37