Pre-run Actions

Pre-run actions are .faction action files that a fusor runs before its automation starts. Use them for one-shot setup the host needs settled before the transition fires: engaging crossfader pass-through, switching an FX bank, preparing a deck. The engine waits for the prerun queue to finish, then starts the transition.

Authoring

Open the fusor in the Library popover (click its info icon, or right-click → Details). On the Actions tab the list is split into two sections, Pre-run and Post-run. The Pre-run section is where you add actions that run before the transition starts.

Click + Add action for a picker listing every .faction file in the library. Click one to add it; duplicates are allowed and run independently.

Per-row controls:

Up / Down chevrons. Reorder. Actions run top-to-bottom.
Orange Switch. Enable/disable. Disabled rows stay in the list but are skipped at run time.
Action name + duration. For example, ~150ms, or unknown if the action has a WAIT_UNTIL step with no override.
Override field. Writing a number saves to the action file's meta.anticipatedDurationMs. Single source of truth: every fusor using the action sees the new value.
Eye icon. Pop out the action editor.
Trash icon. Remove from this fusor's list. A confirmation modal asks first; the file itself is left alone.

Beneath each row there's a per-action preflight editor with the same shape as the per-domain editor on the Domains tab: an Override button that turns into an editable textarea, a reset icon once an override is in place, and a Hide toggle. The preflight text shows up on the player's Before you run this surface when this action is part of the loaded fusor. Override the action's default reminder for this fusor, or hide it if it doesn't apply.

A Total: ~XXXms badge sums enabled author actions plus system-injected contributions. A blue banner appears when the fusor's domains trigger an automatic contribution. Today, FX routing fires when the fusor uses an fx_unit domain with auto-assign on (see FX Routing).

Edits autosave, so there's no Save button. See Authoring Overview → Autosave and undo. Add and remove are not in the text-undo stack, which is why removing a row asks for confirmation first.

Post-run actions

The Post-run section uses the same row UI as Pre-run. Add .faction files there to author actions intended to fire after the transition completes, for symmetric teardown of whatever the pre-run set up (releasing crossfader pass-through, restoring an FX bank, etc.).

When they fire. Post-run actions run after both completion latches are satisfied (progress reaches 1.0 and the outgoing deck reports stopped) and after the engine has swapped roles. The just-finished-incoming is now the outgoing side, so an action that addresses outgoing.* resolves against the post-swap deck.

When they don't fire. Abort skips post-run, since the transition didn't complete and there's nothing to tear down. Manual takeover that runs through to a natural completion does fire post-run; takeover hands you the controls, but the engine still owns the completion gate.

Viewing on a loaded fusor

The fusor's Session View (info icon next to the picker) shows actions inline in its chronological stack: pre-run actions at the top, post-run actions at the bottom, with the fusor's domains between them. Action cards there are read-only apart from the orange enable Switch on each row, which flips the action's enabled bit for the current run only. Authoring (add, remove, reorder, override, preflight edit) happens in the Library popover, not Session View.

Failure and safety

Pre-run

Auto Run Mode. Any pre-run failure aborts the transition.
Manual Run Mode. Failure logs a warning; the transition proceeds.
Hard cap. The pre-run queue must finish within 5 seconds.
Run-length limit. In Auto Run Mode the queue must also be shorter than the transition itself. A queue that would use up the whole transition is refused before anything runs (ACT12) — there would be no time left to mix in. This bites on short transitions: 4 bars at 128 BPM lasts only 7.5 seconds, and a single 8-second action is inside the 5-second cap's reach but not inside that. Manual Run Mode has no such limit.
Over the cap before it starts. If the actions already add up to more than 5 seconds, Auto Run Mode refuses the transition immediately rather than running part of the queue and stopping — you get the message straight away instead of after the wait. Manual Run Mode still runs, because the crossfader move that started it has already begun; it skips whatever the cap cuts off. One long action on its own is never refused: the cap decides whether the next action may start, so the last one always finishes.
Missing actions. The row shows an AlertCircle; engine logs and skips, and the status line names the action it skipped. The run still starts and completes — one broken entry never strands a transition.

Post-run

Per-item failure. Log a warning and continue to the next item. Post-run is teardown; one failing action shouldn't strand the rest.
Hard cap. The post-run queue must finish within 5 seconds.
Missing actions. Logged and skipped, same as pre-run.

A row can only go missing if the action was deleted from the library. Renaming it, moving it into a subfolder, or pointing Fusor Studio at a different library folder all leave the reference intact — a fusor names an action by its id, not by where its file sits. When an action really has been deleted there is no name left to show, so the status message names the raw id instead; the log records it in full.

Author pre-run actions do not auto-restore on completion, so setup like crossfader pass-through persists. For symmetric setup/teardown, attach the matching teardown .faction to the Post-run section above. System contributions like FX routing still snapshot and restore on their own.

Worked example: crossfader pass-through

Goal: a transition that engages Traktor's crossfader pass-through before the transition starts, so pass-through persists afterward.

Library > Actions > + New Action. Add a SET step writing the pass-through value to the crossfader-mode address. Save as crossfader-passthrough.faction.
Open the transition fusor in the Library popover, switch to Actions, click + Add action in the Pre-run section, pick crossfader-passthrough.faction.
Arm and fire. The engine runs the pre-run queue, waits for it to settle, then starts the transition. After completion pass-through stays engaged; no snapshot was taken, so nothing reverts it.

The same .faction file can be attached to other fusors; editing it (or its duration override) updates every fusor that uses it.

Tips

Keep pre-run actions short. The 5-second cap is a hard limit, and on a short transition the run-length limit bites sooner.
Time spent in pre-run is paid back: in Auto Run Mode the transition runs slightly faster so it still finishes when it would have. Your mix always starts at the beginning of its curves — a slow pre-run never skips the opening.
If an action contains WAIT_UNTIL, set a duration override so the Total badge reflects the real wait.
A disabled row is faster than remove-and-re-add when A/B-ing setup steps.
Per-action preflight is the right place for short reminders about what the action expects ("Outgoing tempo should be matched first" for a sync action). A generic reminder that should apply to every fusor using the action belongs in the action's own Pre-flight field on its Notes tab (see Action Authoring Overview → The two tabs). Editing it there only reaches fusors that add the action afterward. A fusor that already lists the action keeps the text it copied when it was added, so update the per-action override here too if the change needs to reach an existing fusor.