PLN: "can we overlay behind a basic spectro? that id remove spectro VSTs
from ardour and wed have our super perf one as overlay on single win?"
So a coarse spectrum of the DEFAULT SINK's monitor -- the mix as the room
hears it, not one orbit -- painted first, under every glyph, in the window
that is already on top of everything. 40 log bands off a 2048-point FFT at
18 Hz: scenery, not an analyser. If something needs measuring, tidal-ears
is the tool and it is the right one.
Off by default and off both ways. `--spectro` or the `s` key acquires the
tap; `s` again hands it back -- the capture subprocess does not exist until
asked and does not survive being un-asked, closeEvent releases it, and the
unit deliberately carries no --spectro so login never acquires one. A live
rig does not get to grow an always-on audio consumer quietly.
Capture and FFT run in one thread whose entire contact with Qt is a single
frame swapped under a lock, depth ONE: a GUI at 5 fps reading an analyser at
18 fps shows the newest picture and discards the rest. A queue here would
only buy latency, which is what a 512-deep queue already cost the HUD once.
pw-record is asked for 100 ms latency explicitly -- a monitor client that
requests a tight buffer is how you talk the graph's quantum down and pay for
a decoration in xruns.
Measured, A/B/A, same -30 dBFS 1 kHz bed in every window, 120 s each: 0
added xruns with the tap on (2249 analysed frames, 18.7/s), 0 in either
control window, every node's counter unmoved. Nothing in the graph noticed.
Two things this cost, both recorded where they bit:
* `Popen(bufsize=0)` hands back a RAW FileIO, so `read(n)` is one os.read
and a hop-sized read is short far more often than not. Treating that as
EOF ended the capture on its first chunk -- blocks=0, no error recorded --
and every pure-function test stayed green on top of a backdrop that could
not receive a sample. Only running it against real audio found it.
`_read_exact` now owns the distinction, with a dribbling-stream test.
* the first assertion about band placement was wrong about the code it
tested: below ~750 Hz a 2048-point FFT has fewer bins than we have bands,
so the edges are not the nominal log ramp, and checking 220 Hz against the
ramp reported MISPLACED for a band that is exactly 211-234 Hz. Ask the
edges where the band is.
And the reference was wrong before the code was: the first bed I labelled an
"80-226 Hz sweep" was 0.02*sin(2*pi*f(t)*t), whose instantaneous frequency
is f + t*df/dt -- broadband chirp garbage. The spectrum was reading it
correctly. A known 1 kHz tone lands in band 22, span 984-1148 Hz, every
other band at 0.00.
`_paint_spectrum` was checked against all 33 methods on the widget before it
was named: `_paint_chrome` had to become `_paint_controls` because a second
method quietly took the first one's name and the selftest went on passing
while a whole layer stopped being drawn.
selftest PASS (bars=40, tap released); 106 tests pass.
