Repository navigation
feat(demos): multi-tool live show — one rule, three real tool bridges - #14
Merged
Merged
Conversation
Two real bugs, both found live while building demos/multi-tool-live-show
— the first thing in this repo to send this bridge a real address in
the exact format its own docstring documents.
- handle_osc_message registered under two overlapping OSC patterns
("/composition/*/*/*" and "/composition/*/*/*/*"). A real 5-segment
address matches both (confirmed directly via
Dispatcher.handlers_for_address returning 2 handlers for one
address), so every real control change was sent to the Conductor
twice — two PCHI messages, two rule evaluations, two signed receipts
per actual change. Only the one pattern this bridge documents is kept.
- parameter was read from parts[4], the fixed "video" category segment
every layer-video address shares, not parts[5], the actual parameter
name. Every real parameter (opacity, strobe_intensity, whatever)
silently collapsed onto target "video" — confirmed via the Conductor's
own log showing resolume_layer_main.video being set instead of
resolume_layer_main.strobe_intensity, so a rule gating on the real
parameter name never fired regardless of the value sent.
Verified live against a real running Conductor: one OSC send now
produces exactly one "[OSC] ... -> PCHI sent" log line and one correctly-
named control parameter, with a rule gating on that real parameter name
now actually firing.
Co-Authored-By: Claude Sonnet 5 <[email protected]>
Two robustness additions, both motivated by real, reproducible failures
seen while building demos/multi-tool-live-show on a machine under heavy
unrelated CPU load:
- Both of this relay's WebSocket legs (to the Conductor, and to a
cables.gl patch) now use a 60s ping_timeout, up from the `websockets`
library's 20s default. A busy peer — a loaded Conductor, a CPU-starved
browser tab — can miss a pong well inside 20s without actually being
dead; this was observed directly as repeated "1011 keepalive ping
timeout" disconnects that went away once the unrelated load did.
- GET /status now returns {"cables_clients_connected": N}, so anything
scripting against this relay can check whether a governance event
actually has anywhere to go before sending a control update and
waiting for a verdict, instead of assuming a connection exists because
a patch's URL field was set once.
Co-Authored-By: Claude Sonnet 5 <[email protected]>
Demonstrates the actual "many tools, one truth" claim: a control update sent through any one tool's real, unmodified bridge is validated and governed once by a real Conductor, and every other connected tool sees the same verdict live — not three separate integrations that happen to agree by convention. One real Conductor, one Only-Lang rule file, three tools' real bridge code from tools/ (resolume-pchi-bridge, tixl-pchi-bridge, cables-pchi-relay — none modified for this). TiXL and Resolume Arena are GUI apps not installed in this environment, so their editors are stood in for by scripts sending the exact real wire shapes those tools' own operators send; the bridges receiving them can't tell the difference. See README.md for the precise, honest accounting of what's genuinely live here versus simulated. Two phases: TiXL raises a shared object to a safe value (every tool sees a signed ALLOW), then Resolume — a different tool's bridge — pushes the same object past the rule's threshold (every tool sees the same signed DENY, proving propagation doesn't depend on which tool caused the update). Building this surfaced two real, previously-undiscovered bugs, now fixed in separate commits on this branch: resolume-pchi-bridge was double-dispatching every message and reading the wrong address segment as the parameter name (silently collapsing every real parameter onto "video"); cables-pchi-relay's WebSocket legs used a 20s keepalive timeout too tight for a loaded peer. Verified live, repeatedly: the TiXL and Resolume legs and the signed governance chain are solid and reproducible — confirmed via listen_as_tixl.py (a real OSC listener, independent of cables.gl) receiving live ALLOW/DENY verdicts regardless of which tool triggered them, and scripts/verify_governance_chain.py confirming every receipt. The cables.gl leg — a real headless Chromium against the real public cables.gl site — is demonstrably sensitive to heavy host CPU load (reproduced across 8 full runs on a machine under ~550% unrelated contention); run_demo.sh does not let that leg's failure block the rest of the demo, and README.md documents this honestly rather than papering over it. The same mechanism was independently proven working earlier in this project's history under lighter load. Co-Authored-By: Claude Sonnet 5 <[email protected]>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
The demo requested as a concrete proof of "many tools, one truth": one real PCHI Conductor, one Only-Lang rule file, three tools' real, unmodified bridge code (
resolume-pchi-bridge,tixl-pchi-bridge,cables-pchi-relay). A control update sent through any one tool's bridge is validated and governed once, and every other connected tool sees the same verdict live.TiXL and Resolume Arena are GUI apps not installed in this environment, so their editors are stood in for by scripts sending the exact real wire shapes those tools' own operators send — the bridges receiving them can't tell the difference.
README.mdis explicit about exactly what's genuinely live versus simulated; please read it before judging what this does and doesn't prove.Two real bugs found and fixed building this (separate commits on this branch, each independently reviewable):
resolume-pchi-bridge: double-dispatch (one real OSC message produced two PCHI messages, confirmed viaDispatcher.handlers_for_addressreturning 2 handlers for one address) and a wrong parameter index (every real parameter name silently collapsed onto the literal"video"category segment — confirmed via the Conductor's own log showingresolume_layer_main.videoinstead ofresolume_layer_main.strobe_intensity, so a rule gating on the real parameter name never fired).cables-pchi-relay: both WebSocket legs now use a 60s keepalive timeout (up from the library's 20s default) and exposeGET /status— motivated by real, reproduced connection drops under heavy host CPU load.What's solid vs. what's flaky, honestly
listen_as_tixl.py— a real OSC listener standing in for TiXL's ownOscInput, entirely independent of cables.gl — receives live ALLOW/DENY verdicts regardless of which tool's bridge triggered them, andscripts/verify_governance_chain.pyconfirms every receipt independently.run_demo.shdoes not let that leg's failure block the rest of the demo (Phase A/B run independently, each reports PASS/FAIL separately, and the Conductor log + governance export + verifier output are never gated on it). The same mechanism was independently proven working earlier in this project's history under lighter host load — this PR doesn't claim it's broken, only that it's environment-sensitive, and says so plainly in the README rather than hiding it.Test plan
cargo test --workspace— 40/40 passing (unaffected by this change; Rust side untouched)cargo clippy --workspace --all-targets -- -D warnings— clean[OSC] ... -> PCHI sentlog line and the correctly-named control parameter, with a rule gating on that real name actually firing🤖 Generated with Claude Code