Skip to content

Compose

Video tutorial — coming soon

Compose turns everything you authored — pose layers and their keys, controls, knobs, drivers, constraints, visibility groups, look-ats — into a real Master Controller node in your Harmony scene, plus the files that node needs.

It is the only thing in ORC that writes to your scene.

The MC name

Type a name in MC Name. You do not need the suffix:

You press ORC does
Enter, or click away Appends -MC if it is not already there. HeadHead-MC.
Enter again Clicks Compose.

The check is case-insensitive, so a name you typed as head-mc is left exactly as you typed it.

There is no other validation — no character stripping, no uniqueness check. Harmony decides the final node name, so a colliding name can come back changed, and ORC reports the name it actually got.

Why Compose is disabled

The tooltip is always the reason, and always something you can act on:

Tooltip Fix
Enter a name for the Master Controller first. Type a name.
The "Eyebrows" pose layer has no keys yet. Stamp a snap with F6 or delete the empty layer. Key it, or delete it.
3 layers are keyed but have no targets (…). Add what each one should move to its target list. Give them targets. A widget that moves nothing is not shippable.
Nothing to compose yet. Add poses, drivers, constraints, or look-ats — or set both Front and Back MC to bake a merged runtime. There is nothing in the rig.

Compose is enabled when the name is filled, no layer is half-finished, and at least one of:

  • at least one pose key anywhere,
  • both a Front and a Back MC are set (you are merging them),
  • zero pose layers but at least one driver, constraint or enabled look-at — a rig that is only automation composes fine.

Layers that never need keys — a control's faces, a knob, an imported grid — are exempt.

Two things that stop it

Blockers — refused outright

Conflict Why it cannot work
Knob conflict Two or more extra knobs writing the same node and channel. The runtime captures one pristine base per node and attribute, so those writes cannot sum — the last one would silently win.
Drawing conflict One READ node swapped by two or more sibling layers. A drawing swap is discrete, so it cannot blend, and nothing ranks siblings.

You get a red line naming the conflict, and Compose does not start. The offending Outliner row is lit red too.

A drawing swap shared down a hierarchy is fine — the deeper layer winning is intentional.

Warnings — confirm and continue

If anything is merely suspicious, the button becomes CONFIRM? for five seconds with the list beside it. Let it run out and it goes back to Compose.

  • No pose data loaded
  • No Front or Back face: import an MC or author one — only when there is neither. Front-only is normal.
  • Driver 'Blink' (Eyelids) has no keyed values
  • Constraint 'Arm Follow' has no target nodes
  • Constraint 'Arm Follow' has no channels selected

Compose Settings

Compose Settings

Setting What it decides
Save states / script to Where the .tbState files, the runtime script and ORC's data files are written. Defaults to your scene's scripts folder.
Connect MC to composite Which Composite the new MC is linked into. ORC pre-selects its own best guess; the full list of composites in the scene is always available.
How the guess is made

The pick is derived from the rig itself, not from list order.

First ORC finds the rig's main group: every target-list node votes for all of its ancestor groups, and the deepest group holding a majority of the targets wins. Depth is what keeps a deformation group from claiming the vote — it only ever contains its own handful of members, so the majority always lands on the character group outside it.

Inside that group, the first match wins:

  1. A composite an existing MC already feeds — most MC links first. If one is inside the main group, it wins outright.
  2. A composite whose name follows master-controller conventions — master-controller, masters, controllers, ctrl, -MC
  3. The group's main composite — the one feeding its Multi-Port-Out.
  4. No composite inside the group at all → the one the group node itself feeds on the outside.

Nothing matched → the scene's first composite. Whatever it picks, it is only a pre-selection — the combo always lists every composite in the scene.

Keep the same output folder between composes

The incremental cache lives there. Reusing the folder is what makes a re-compose fast.

If no composite is chosen, the MC is created in Top and left unlinked. Otherwise it is created in that composite's parent group and placed just above it in the Node View so you can find it.

What happens

Composing

Four phases, all reported live:

Phase What it produces
Slicing state files… The .tbState pose stacks, one per layer/side/page, plus the manifest. The detail line names exactly where it is: "Layer 'Eyebrows-L' — Pose 3 of 25 · Knob 2 of 13".
Constraint pre-wiring… Records each constraint's original columns so its toggle can restore them.
Generating MC script… The runtime script the MC will execute.
Assembling MC node in Harmony… The node itself, its attributes, its UI script and data, and ORC's own blobs.

The Recent activity log below keeps a timestamped record, including any warnings.

One Ctrl+Z undoes a Compose

The whole assembly runs inside a single Harmony undo step named ORC Compose.

The slicing phase does write columns — that is how it reads your poses — but those writes are transient, discarded, and your pose is restored afterwards whether Compose succeeds, fails or is cancelled.

Cancelling

Cancel is a two-click confirm: the first click arms it for four seconds (CONFIRM? (4s)), the second cancels. The window's behaves the same way — a running Compose never just closes. Enter never triggers Cancel, so a reflexive keypress cannot abort a half-built MC.

The cancel is cooperative: it stops at the next safe boundary, never mid-call, so you will see "Will stop after the current Harmony call returns…".

What a cancel leaves behind:

  • Cancelling during slicing: the .tbState files already written stay, and the cache is saved so the work counts toward the next run. No MC node is created.
  • Cancelling after assembly has started: the node exists. There is no transaction over the whole compose — Ctrl+Z on the ORC Compose step is the way back.
  • Either way, your pose is restored.

How it ends

Result What it means
Compose complete — Top/robin-head-MC | 12 state stack(s), 2 constraint(s) Done. The Node View pans to the new node and selects it.
Compose finished with 3 warning(s) — see the log The MC exists and works, but a non-fatal step had a problem. Read the log.
Compose failed — no state files produced Nothing was sliceable.
Compose failed — script generation error
Compose failed — MC assembly error: …

What lands on disk

In the output folder you chose:

File What it is
<Stack>.tbState, or <Stack>/0.tbState, 1.tbState The pose stacks. A layer with a knob gets a folder, one file per knob position — Toon Boom's own native layout.
<folder>_compose_state.json The runtime manifest.
<name>_orc.js The generated runtime script.
orc_pose_data.json Your whole rig configuration — the source for re-editing and for the standalone Widget Editor.
orc_session_state.json The authoring UI state, so reopening restores your workspace.
.orc_cache/snaps.json The incremental-compose cache. Not part of the rig; safe to delete.

Stack names are derived from your layer names — Eyebrows and Eyebrow both become Eyebrow, sides append L/R, back stacks append Back, pages append their number.

What lands on the node

Besides the runtime script and its data, ORC writes three of its own blobs onto the MC node: your pose data, your session state and the manifest. They are embedded inline only when each is small enough; anything larger stays on disk, because embedding megabytes of text into a Harmony attribute crashes its script engine on read.

A small pointer attribute records the output folder's scene-relative path, which is how re-edit and unroll find the rest.

Keep the output folder with the scene

The MC reads its state files from disk at runtime. Move the scene without them and the rig has no poses to load. The path is stored scene-relative so moving the pair together is safe.

Re-composing

Composing again over the same rig is normal and expected — it is how you iterate.

Because ORC stores frame references rather than baked poses, you can go back to frame 861, fix the eyebrow, and re-compose: the change is picked up. Nothing needed re-keying.

The incremental cache means a re-compose only re-slices what actually changed, which is why keeping the same output folder matters.