Wiring the Bay
The Variables panel draws every variable your expression uses as a literal wire to its target.
One panel, drawn as wires
Open the panel from the IDE toolbar's Variables button, ⌃⌘T, or the command palette. It's draggable and resizable, and it remembers its position and size across sessions.
These screenshots were captured in an earlier beta. Toolbar and Library layouts have since changed; the written instructions on this page describe v0.145.4. See A Tour of the Panel for the current controls.
Dragging a wire
Drag a wire from a variable to any Targets row — a new control, an existing property, or on apply — to wire or re-wire it. There's one wire out per variable, and re-wiring replaces rather than merges: dragging a variable's wire onto a different endpoint moves it there, it doesn't add a second connection.
The quick-wire menu
Click anywhere on a variable's row — not its port — to open its menu without touching Targets at all: New control, Link property…, Ask on apply. Same three destinations as the drag, reached without leaving the variable side of the bay.
New control wires the variable straight to a fresh control, built at the type the variable already resolves to — a Slider for a 1D value, a Point for 2D, a 3D Point for 3D, a Color control for a color, a Layer control for a layer reference — with no kind to pick in the moment, since the kind was never the variable's decision (that choice lives on the control's own Targets row; see Delivering Controls). It's dimmed, with its reason written underneath, on a variable whose type isn't established yet or that no control can hold — text, for instance. Reach for Link property… or Ask on apply instead.
Link property… opens the pickwhip so you can point the variable straight at a live AE property. Ask on apply sends it to the always-visible port described below.
The layer stays swappable, the path stays fixed
Link a property scoped to one specific layer — thisComp.layer("Ctrl").transform.position, say — and its Targets row offers a second way to deliver it, alongside linking the property outright: Layer Control · keep .transform.position. Picking it creates a Layer Control instead of linking the property directly: the layer becomes pickable — swap which layer the wire points at from the control, no code edit required — while the path after it, .transform.position, stays exactly as written.
It's a clean fit for transform-family tails, since every layer carries one. It's offered for an effect tail too, with an honest note attached: the layer you point it at has to actually carry that effect, or the reference breaks — eXLib can offer the option, but it can't guarantee every layer qualifies.
Sharing one target across variables
Several variables can share one target — the same property, or the same control — on a single endpoint row. Editing that row's name or path re-points every variable riding on it at once. Targets rows carry their own grip and their own persisted order, so an arrangement you set up survives a regroup, a reorder, and an unwire/rewire.
The type chip is derived, not chosen
A variable's type renders as a read-only chip — 1D, 2D, 3D, COLOR, CHECK, MENU, LAYER, TEXT, or TBD — and it always states what the variable actually needs, read from the evidence: the live composition first, then the shape of the reference it captured, then its declared type. It is never a readout of the control you picked. Choosing a Checkbox for a 2D capture doesn't turn the chip into CHECK; the chip keeps saying 2D and warns, because the variable's need didn't change when your pick did.
A variable nothing can judge yet reads TBD — "Type not established yet — it is inferred as your expression uses the variable" — and it keeps reading TBD whether or not a control kind has been chosen for it. Picking a kind is a decision about the control, not a statement about the variable.
Where the chip and your pick disagree, the disagreement is stated in every place it's visible rather than in only one of them: the chip turns caution-toned and names the conflict, the control's kind menu marks your pick as chosen and warned, and the Targets endpoint says the same sentence in place without your having to open the menu. Nothing is blocked — every kind stays selectable, and a warned wire still applies. A type-mismatched link tones both its port and its wire, and the tone carries meaning: a blocking mismatch paints error, a non-blocking one (a 2D variable wired to a Slider, say) paints warning instead — an appliable-but-imperfect wire is never painted the same red as one that genuinely can't apply.
Nothing is implicitly deleted
Every control endpoint is removable at any time, which un-wires whatever variables it drove. But re-wiring a variable away from a control doesn't delete that control — it becomes a free, unwired endpoint in the Targets column, exactly like a control you added but haven't wired up yet, there to pick back up rather than silently gone. Only its own trash icon actually removes it.
The ask-on-apply port
Below the PROPERTIES section sits a single, always-visible ask-on-apply port with unlimited fan-in — any number of variables can wire to it. It's structural rather than conditional: it doesn't appear only when something is unresolved, it's simply always there as the third target kind alongside a new control and a linked property.