Delivering Controls
Once a variable is wired to a new control, two more choices decide what actually gets created: how the controls are packaged, and which of eight kinds each one becomes. eXLib advises on both — it never restricts.
Native controls or one pseudo effect
A segmented control at the top of the Variables panel picks how "new control" targets get built:
- Native controls — each becomes its own individual AE Expression Control effect (Slider, Angle, Color, Checkbox, Point, 3D Point, Layer, or Dropdown Menu) on the target layer.
- Pseudo effect — every one of them is instead delivered as parameters of a single custom pseudo effect.
A layers-only pickwhip cell next to the segmented control chooses which layer newly created controls land on, defaulting to your target layer.
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.
Auto and Guided build styles
Choosing Pseudo effect discloses a build style: Auto, where eXLib assembles the rig for you, or Guided, which hands your bound controls to Pseudo Effect Authoring so you can arrange them yourself — saving there returns you to the Variables panel with the rig wired in.
Choosing where controls land
The layers-only pickwhip cell always defaults to your current target layer, but you can point it at any other layer in the comp before you apply, so the created controls end up wherever makes sense for your rig rather than always on the layer the expression lives on.
Picking a control kind
Once a variable is wired to a new control, its kind is chosen on that control's own row in Targets — never on the variable. Click it to open the kind menu — Slider, Angle, Color, Checkbox, Point, 3D Point, Layer, or Dropdown Menu. (The variable side only ever offers New control, Link property…, or Ask on apply — see Wiring the Bay.)
The menu answers two different questions at once, and marks them differently:
- The kind that fits — the one the variable's evidence says it needs — is check-marked and shown at full weight.
- The kind you picked is drawn as the row this control is, with the selected background and accent bar the rest of the panel reserves for that meaning.
- Everything else is dimmed, each dim row carrying the reason it was held back.
When the two are the same kind, one row wears both marks. When they differ, your pick keeps the "this is what's chosen" treatment and gains a warning tone and a sentence naming the conflict — "radius is 2D — Checkbox Control emits a checkbox; use a Point control" — while the fitting kind keeps its check. The same sentence appears on the variable's type chip and on the endpoint's own kind button, so the reason reads identically wherever you meet it. Nothing is blocked: a contradicting pick applies exactly as picked.
With nothing to judge yet — an unbound variable, or one whose shape can't be classified — no kind is check-marked, and an endpoint that nothing has typed and nobody has pinned draws a plain — rather than guessing at a Slider.
The fit check folds every wired variable together where a target is shared: a kind is only marked as fitting when every variable riding on that endpoint accepts it, and a misfit reason is attributed to the specific variable name that objects. Where the sources genuinely disagree, the endpoint says so — one control can only have one kind.
Classify, never prune
This is the standing rule on every control-kind menu in eXLib: all eight kinds stay offered and none is ever disabled or hidden. The fit mark is advisory only — a nudge toward the kind the variable needs, never a restriction that decides for you. And the fit mark is deliberately not amber: amber means selected or active everywhere else in the app, so "this fits" reads as a success-toned check instead, keeping it visually distinct from "this is what's chosen."