Pre-run Actions

Pre-run actions are .faction action files that a fusor runs before progress starts. Use them for one-shot setup the host needs settled before the transition fires: putting the crossfader into bypass, switching an FX bank, preparing a deck. The engine waits for the prerun queue to finish, then starts the transition. Post-run actions run after the transition completes.

A step that sets a control takes a few milliseconds, so a queue of them starts the transition with no delay you can notice. The only pre-run time you will notice is a WAIT or WAIT_UNTIL step you add to an action yourself.

Authoring

Open the fusor in the Library window (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; adding the same action more than once is allowed, and each row runs independently.

An action that's a flagged duplicate copy shows the same orange duplicate mark in this picker, and on its row once added. See Action Authoring Overview → Where files live for how a duplicate is flagged.

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.
Update mark. A blue up-arrow mark after the name when the row uses an older version of an example action and a newer version is in your library. Click it to put the newer version in this row. The row then behaves as if you had just added it: the preflight reminder is taken fresh from the newer version, and any override or hide on the row is dropped. Shown here only, not in Session View. See Example versions.
Override field. Only on an action with a WAIT_UNTIL step, whose length depends on the DJ app. Writing a number saves to the action file's meta.anticipatedDurationMs, so 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, above the preflight editor, an action shows a computed line for every SET step that lands on a control with a fixed number of positions, naming the one position that step sends:

Tempo Range Selector: 50%
Mixer FX Selector: position 2 (Reverb)

Fusor Studio recomputes it from the action file at every render, so editing the .faction in the action editor updates it here on the next read. There's no field behind it and nothing to type. An action whose steps don't touch a counted control shows no line at all.

Directly below it, in orange, sit any warnings from reading the action: a step naming a position the control doesn't have, or a step writing to a control that can only be read. They do not stop you authoring, and they tell you the action will fail at that step when it runs.

It's the same line the Fusor player shows before a run. The full description, covering both shapes, the two-deck A: prefixes, why a control whose positions you named yourself leads with the position number, and why no count appears anywhere, lives at Loading a Fusor → What the card says it will send. It is on this tab so you can check what an action does before a fusor depends on it.

Beneath that 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 Fusor 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. Hide reaches your reminder text only; the computed line and any warnings above it stay put.

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: taking the crossfader back out of bypass, restoring an FX bank, and so on.

When they fire. Post-run actions run after progress reaches 100% and the outgoing deck reports stopped (or you press End), and after the roles have swapped. The deck that was 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. A manual takeover that runs through to completion still fires post-run.

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 enables or disables the action. The change is saved to the fusor file. An action card whose action is a flagged duplicate copy shows the same orange duplicate mark beside its name. Authoring (add, remove, reorder, override, preflight edit) happens in the Library window, not Session View.

Failure and safety

Pre-run

Auto Run Mode (and Mixed Run Mode, which starts as Auto does). 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), because there would be no time left to mix in. This matters on short transitions: 4 bars at 128 BPM lasts only 7.5 seconds, so a single 8-second action is refused by the run-length limit, even though the 5-second cap lets one long action finish. 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, so 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, and 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 alert icon; the action is logged and skipped, and the status line names it. The run still starts and completes.
Actions that name a value that doesn't exist. Same outcome, same message. An action whose step names a position a control doesn't have is left out of the queue before anything is sent, and the status line names it. Nothing it would have done is done, including the steps before the problem, so your decks stay where you left them rather than ending up half-configured at the moment a mix starts. The rest of the queue runs normally.

Post-run

Per-item failure. Log a warning and continue to the next item.
Hard cap. The post-run queue must finish within 5 seconds.
Missing actions, and actions naming a value that doesn't exist. Logged and skipped, same as pre-run. Post-run runs after the roles have swapped, so a half-applied action there would be configuring the deck that is now playing out, which is why it is dropped whole rather than part-run.
A RESTORE of a snapshot from another run. A post-run RESTORE puts back only a snapshot captured during the same run, by that run's pre-run or post-run actions. A snapshot of that name from an earlier run or a pad press is not sent: the step fails, and the status line reports the post-run action as failed. The same action played from a pad restores the most recent snapshot of its name.

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, because a fusor names an action by its id rather than 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 bypass 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 bypass

Goal: a transition that puts Traktor's crossfader into bypass before the transition starts, and leaves it there afterwards.

Library > Actions > + New Action. Add a SET step writing the bypass value to the crossfader-assignment address. Save as crossfader-bypass.faction.
Open the transition fusor in the Library window, switch to Actions, click + Add action in the Pre-run section, pick crossfader-bypass.faction.
Start the transition. The engine runs the pre-run queue, waits for it to settle, then starts the transition. After completion the crossfader is still in bypass; 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.

Four things to know

Pre-run time comes from waits. The 5-second cap and the run-length limit only reach a queue whose actions contain WAIT or WAIT_UNTIL steps, and on a short transition the run-length limit applies sooner.
Time spent in pre-run is made up: in Auto Run Mode the transition runs slightly faster so it still finishes when it would have. The mix always starts at the beginning of its curves, so 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.
Per-action preflight is the 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.