A patch change builds a whole Rack on the UI thread

[bdbarnett]

One app.poll() in ten minutes on the Waveshare ESP32-P4 hit 222 ms at a
patch change. It is the same build-off-thread problem the engine owes, arriving
here as a visible hitch.

From #123.

[bdbarnett]

On the LilyGO T-Embed S3 this is no longer a hitch, it is a hole you can hear. Building the new Rack takes 395–1036 ms on the interpreter thread and drops 0–176 ms of audio per change, and no ring depth covers it: a 190-second rack_knob run that keeps changing pedalboard reads 3749 ms starved at 12 × 256, the same ring that reads 0 ms through thirty seconds of continuous knob turning, five times out of five (#130).

So this is what stands between rack_knob and a clean long run on that board. The two ways in that were named at the bench: build the Rack off the interpreter thread, or reuse the nodes two chains share instead of building every pedalboard from nothing.

[bdbarnett]

Heard on the T-Embed S3 on 2026-09-21: the hole at a pedalboard change is "very short and is acceptable, even for a live setting" (the owner, at the bench, after changing patch several times). So this is not urgent on that board. It stays open for the structural reason — a Rack is still built on the UI thread, which is the 222 ms app.poll() hitch on the P4 — and for a long run's starved line, which a patch change is the only thing left moving.

[bdbarnett]

A refinement from a run on 2026-09-21 (T-Embed S3, 12 × 256 ring, knob turning every 30 ms, one pedalboard change at t = 8 s):

t= 5s  load=89%  worst=8518us  starved=0ms
t=10s  load=91%  worst=8546us  starved=37ms     <- the change itself
t=15s  load=95%  worst=9645us  starved=416ms    <- five seconds on the NEXT pedalboard

So it is not only the change. The change cost 37 ms here; the other 379 ms arrived afterwards, while nothing was changing, because the pedalboard it landed on runs at 95 % of a block with a 9.6 ms worst case and cannot keep a 64 ms ring full while the knob is being turned. Part of the 3749 ms that a 190-second run reads is pedalboards that are simply too heavy for this chip at 48 kHz, not the rebuild.

Two separate things to fix, then: build the Rack off the UI thread (the hole at the change), and either cost-gate the pedalboards rack_knob offers on an S3 or say beside each what it costs (the starvation after it). The owner's ruling that the hole is acceptable live was about the change; he has not been asked about a pedalboard that starves for as long as it is selected.

[bdbarnett]

Parked (Arthur, 2026-09-22) with audiodsp#108 and #109 as one design; see audiodsp#108.

[bdbarnett]

Trigger updated (Brad, 2026-09-23). The retool this was waiting on is done. It reopens when live use shows the hole or a tear, for example a stompbox build or playing out. Brad ruled the current behaviour acceptable live on 2026-09-21. The three issues (audiodsp#108, audiodsp#109, pydevices-examples#126) are one design and get one sitting.