Node Editor: Connections Not Firing

Diagnose why node graph connections appear correct but signals are not flowing, nodes are not executing, or outputs are not producing expected values.

Before you start

• Open the Node Editor and confirm the graph is loaded.

• Confirm at least one signal source exists (Control:LoadBang, UI:Button, Network:UDPReceiver, or similar).

• Enable Debug mode from the Node Editor toolbar to see signal activity on connections.

Symptom: Node receives data but does not execute

Cause: The input is cold

Every input pin is either hot or cold. Only a hot input triggers the node to execute when data arrives. A cold input stores the value silently — the node uses it only when a hot input fires next.

Filled shapes = connected. Outline shapes = unconnected.

Fix: Send your value to the cold input first, then send a Bang or value to the node's hot input to trigger execution.

Symptom: Outputs fire in the wrong order

Cause: Execution order within a trigger cycle

When a node fires multiple outputs, they are emitted top to bottom. Every downstream chain from the first output completes before the second output fires. If your graph relies on value A being set before action B runs, the order of outputs on the sending node matters.

Fix: Use a Control:Trigger node to define explicit ordering. Place the output that must fire first higher in the Trigger's output list.

Symptom: Signal stops mid-chain with no error

Cause: Recursion blocker

Backstage prevents infinite loops. If a signal traveling through connections reaches the same connection a second time within a single signal chain, the recursion blocker silently drops the signal — no error, no visual indicator. This happens when you create a feedback loop: Node A → Node B → back to Node A.

Fix: Insert a Control:Desync node at the feedback point. Desync defers execution to the next processing cycle, starting a new signal chain so the recursion blocker does not see the same connection twice.

Important: Use Desync only where feedback is intentional. Each Desync adds one processing cycle of latency.

Symptom: Node fires once but ignores repeated identical values

Cause: Control:FlancGate blocking repeated signals

A Control:FlancGate node blocks its output if the same input value is received consecutively. It only passes a value through when it differs from the previous one. This is useful for debouncing but silently swallows repeated identical values.

Fix: Check if a FlancGate exists in the signal path. Remove it, or insert a Control:Trigger before it to convert the value to a Bang (which always passes through).

Symptom: Connection exists but data type seems wrong

Cause: Type mismatch on the connection

Backstage only connects pins of the same data type. Each pin index can have multiple type slots (Bang, Int, Float, String, etc.). When you draw a connection, it links the matching types automatically. If you connect a String output to a node that also has an Int slot on the same index, the connection links String-to-String — not String-to-Int. The node receives a String even if you expected an Int.

The Control:Trigger node handles explicit type conversion. If a conversion fails, the Trigger's tag label turns orange as a warning.

Fix: Use a Control:Trigger or Datatype:Converter node to explicitly convert between types. Check that the Trigger's type string matches what downstream nodes expect (b=Bang, i=Int, f=Float, s=String).

Symptom: Nothing fires when the graph loads

Cause: Missing Control:LoadBang

The graph does not automatically send any signals when it loads. You need a Control:LoadBang node to emit an initial Bang after the graph finishes loading. Without it, no signal chain starts until a user interaction or external trigger occurs.

Fix: Add a Control:LoadBang node and connect its output to the first node in your startup chain.

Options explained

Common Mistakes

• Sending data to a cold input and expecting the node to react. The node stores the value but does not execute. The connection animates in Debug mode, but nothing happens downstream. Verify the receiving pin is a circle (hot). If it is a square (cold), send your trigger to the node's hot input after setting the cold value.

• Creating a feedback loop without a Desync node. The graph looks correct and connections are drawn, but the looped portion never executes after the first pass. The recursion blocker silently drops the signal. Insert a Control:Desync at the feedback point.

• Assuming Control:Trigger outputs fire simultaneously. Trigger outputs fire sequentially, top to bottom. If downstream logic depends on two values being set at the same time, the second value is not available until the first output's entire chain completes. Reorder outputs so dependencies resolve top-down.

Tips

• Use Debug mode to see which connections carry signals. Active connections flash briefly, making it easy to trace where a signal stops.

• Hover over any pin to see its type and last-received timestamp. If the timestamp is old or absent, the pin has not received data recently.

• Connect an Unspecified:FiFoLog node to a suspicious output. It displays the last 10 received values as strings, which helps identify whether data is arriving with unexpected content.

• The Control:Trigger type string supports special shortcuts: 0 always outputs integer 0, 1 always outputs integer 1, * outputs a Pack.

Related

• Node Editor — overview of the Node Editor window and toolbar

• Control:LoadBang — emits a Bang when the graph finishes loading

• Control:Trigger — explicit execution ordering and type conversion

• Control:Desync — breaks signal chains for intentional feedback loops

• Control:FlancGate — blocks consecutive duplicate values