Oratorian
50c7af0b4b
A source node that lives next to your booleans (typically inside a
subgraph) and relays them to Group/Node Controllers elsewhere. It reads
booleans in its own graph (always reliable) and delivers the result the
safe way, sidestepping the flaky cross-boundary boolean reads.
Fully automatic: each tick it walks its patch output to discover the
Controllers it feeds - up out of its subgraph, across at the root, and
down into sibling/nested subgraphs - pulls their target labels, and
auto-creates one boolean input per target (no manual signal naming). It
resolves those booleans locally and pushes the result onto every
Controller on the lane, so one Wired Controller fans out to many
(Group and Node, mixed). A patched signal governs its target and
overrides ALL, just like a direct boolean; a target's own direct boolean
wins for that one target.
Two bindings (wire tried first, channel is the fallback):
- wire: WiredController `patch` output -> Controller `patch` input,
followed across boundaries by a robust output walk (link map +
floating links + reverse output-proxy lookup; host matched by id and
identity; descends into sibling subgraphs).
- channel: name-keyed global registry, no traversal, any nesting depth.
Controllers gain a `patch` input and a `channel` field (both inert until
connected). The bus socket is named "patch" (SWITCHBOARD_PATCH) to fit
the Switchboard theme; older saved nodes are normalised on load. Boolean
resolution refactored into shared module functions. Adds a Wired
Controller diagnostics menu. README + example_workflows notes updated.
2.3 KiB
Example 3 - Wired Controller
Keep your booleans in one tidy subgraph and drive Controllers anywhere - across subgraph boundaries, reliably.
A Wired Controller is a source. It sits next to your booleans (usually inside a subgraph), reads them in its own graph (always reliable), and relays the result to the Group/Node Controllers that hold the real targets.
Set it up
- Inside a subgraph, drop your booleans (e.g. Value on Boolean, promoted subgraph-input booleans) and a Wired Controller.
- Connect the Wired Controller to the Controllers it should drive, by either:
- Wire - run its
patchoutput across a subgraph output (IO) into each Controller's↦ patchinput. One output can fan out to many Controllers (Group and Node, mixed). - Channel - type a name in the Wired Controller's
channelfield and the same name in each Controller'schannelfield. No wire needed - works at any subgraph nesting depth.
- Wire - run its
- That's it - it fills itself in. The Wired Controller reads the targets
already on the Controllers it feeds and auto-creates one
BOOLEANinput per target, labelled to match. Add/remove a target on a Controller and its inputs follow. Just wire your booleans into the inputs it grows.
How it behaves
- A signal governs its target exactly like a directly-wired boolean:
true= enabled,false= disabled (using that target's↳ disable asmode), and it overrides the masterALLtoggle. - A target's own direct
BOOLEANinput, if also wired, wins for that one target. - An input you leave unwired is ignored - that target stays on manual /
ALL.
Why use it instead of wiring a boolean straight in
Reading a boolean across a subgraph boundary is best-effort and can get confused when several subgraphs are in play. The Wired Controller flips this to the reliable side: it reads booleans in their own graph and delivers the result in the safe direction (out of its subgraph, across, and down into the target's subgraph). Result: a subgraph holds just booleans + one Wired Controller, while the real targets stay on Controllers in the parent graph - one tidy box of switches drives the whole pipeline.
Tip: running two Wired Controllers? Give them distinct channel names so their signals don't merge.