fix(obs): detect activity by MOVEMENT, not by level — two wrong versions later
rig-pulse answers one question when the sound stops: did Tidal stop asking, or did the engine stop playing? It got that wrong twice, in two different ways, and both are the same mistake wearing different clothes. v1 assumed a universal idle threshold: SOUND if synths > 0 or peak CPU > 1.5%. But this rig idles at 71 synths / 3531 ugens / 17.7% peak — start_and_midi.scd registers the Mutable-Instruments global effects on all 14 orbits and those synths never die. So the tool reported SOUND continuously, straight through a silence PLN was actively complaining about. It could not have fired. I shipped a check that cannot fail one commit after writing a message about how a check that never fires is indistinguishable from a check that passes. v2 learned the floor as a running minimum. Also wrong, and only live data showed it: the floor RISES as more of the graph gets instantiated — 71 synths at 15:02, 103 at 15:05. A baseline that only ratchets down cannot track a rig that ratchets up, so everything above the all-time minimum looks like activity forever. What separates the states is stillness, and the data said so plainly: an idle SuperDirt returned ugens=3531 five times over eight seconds — exactly, not approximately — while a played rig moved 4144 -> 4300 in two seconds. So compare the last few samples to each other and ignore the level entirely. That is immune to the floor changing between boots or during one. Known limit, in the header rather than hidden: a perfectly static drone with a constant voice count would read SILENT. Tidal events are discrete and the count moves, so it holds for how this rig is played. Verified against both states: frozen at 103 synths / 4144 ugens -> SILENT; moving 4066-4222 -> SOUND.
Showing
Please
register
or
sign in
to comment