Action Authoring Overview

Actions are deterministic, scripted sequences of control changes that Fusor Studio runs in three contexts: as a fusor's pre-run or post-run step (Pre-run Actions), as a pad-mode trigger (Pad Mode), or as a one-shot manual run from the Library.

The editor runs inside the Library window and is where you create, edit, duplicate, and delete .faction files.

Opening an action for editing

Open the Library with the book icon in the toolbar and switch to the Actions tab. The Actions sub-tab lists every .faction file in the library.

Edit an existing action. Click an action to open its detail view, or right-click → Details. The detail view is already editable.
Create a new action. Click + New Action (the blue + in the list header). An in-app prompt asks for a name; there's no file-explorer dialog. Fusor Studio writes the file into your library's actions/ folder for you.
Duplicate an existing action. Right-click an action and choose Duplicate. The prompt proposes "name copy"; confirm or type a different name. The copy keeps the original's description, app tags, preflight note, and steps; the actionId is regenerated for the new file.
Delete. Right-click → Delete. Confirm the prompt and the .faction file is removed from disk.
Show every version of an example. Right-click an example action and choose Show All Versions, offered when another version is in your library. Saving an edit to an example makes it your own action and removes its version number. See Example versions.
Rescan the folder. The Scan Folder button (refresh icon in the list header) rescans actions/ for files added or changed outside the app.

Canceling either prompt writes nothing. If the name you typed is already taken, Fusor Studio still creates the action: the file on disk gets a number appended (crossfader-bypass-2.faction, and so on) so nothing gets overwritten. The list still shows the display name you typed, duplicate or not.

There's no separate "enter authoring" step, no Save/Cancel bar on the main detail view, and no pencil button to switch into edit mode.

Files Fusor Studio can't read. A .faction file that isn't valid JSON, or that parses but isn't an action, still shows up: a greyed row named after its file, sitting at the bottom of the list. Clicking or double-clicking it does nothing. Right-click it for Show in folder, which opens Explorer or Finder with the file selected, so it can be fixed or deleted there. Hover it for a tooltip naming the problem, for example "Can't read this file (not an action file). It reappears once fixed or synced. Right-click and choose Show in folder." Fusor Studio never modifies the file; fix it on disk and click Scan Folder to turn the row back into a normal one. A file saved with a leading byte-order mark, which some text editors and sync tools add, reads normally rather than showing as broken.

When the actions/ folder itself can't be opened (a permissions problem, a sync app that's offline, or the folder replaced by a file), the list shows one greyed row with an orange folder icon reading "Can't open the Actions folder". Hover it for a tooltip naming the problem, for example "Can't open this folder (no permission). The list updates when it opens. Right-click and choose Show in folder." Clicking or double-clicking it does nothing. Right-click it for Show in folder, which opens Explorer or Finder at your library folder with actions selected. It sits last. Actions from the last successful scan stay listed above it and still load. A newly created library with an empty actions/ folder shows no such row.

Duplicate copies. If an action and a copy of it made outside Fusor Studio, such as an Explorer "name - Copy", a Finder "name copy" or a OneDrive conflict copy, both sit in the actions/ folder, both rows show a small orange duplicate mark next to their name. Hovering either names the other file and confirms which one packs reference. See Where files live below for how Fusor Studio decides which file is the original.

The mark isn't limited to this list either. It also appears, icon only, on a pad in Pad Mode (the pad's tooltip ends with the same sentence) and in the pack slot editor's unassigned list and slots, and with the word in the pre-run action picker, on pre-run and post-run rows, and on Session View's action cards.

Autosave

Edits to the action's metadata commit as you make them. There's no Save button on the detail view.

Text fields (name, description) commit on blur: click out of the field, or press Tab.
Apps multi-select commits as soon as you change the selection.
Code tab (the raw DSL text) commits on blur of the text area.

Editing an action's metadata triggers a rescan so the list view picks up the new name or app tags without a Scan Folder click.

Action edits are not in the fusor editor's undo stack, which belongs to the loaded fusor. If you make a typo in an action's name or description, fix it the same way (blur to commit, edit again, blur again). For larger changes to the steps, work in the pop-out Step Editor, which has its own explicit Save and an "unsaved" indicator.

The two tabs

The action detail view has two tabs along the top:

Tab	What it's for
Notes	Metadata: Name, Description, Pre-flight, Apps (a multi-select picker of DJ-app tags from the registry: Traktor, Mixxx, djay, Virtual DJ, rekordbox, Serato). App tags are informational and do not gate execution.
Code	The action's steps as raw DSL text. Lives in a single text area with inline parse-error feedback. The pencil icon in the tab bar opens the structured pop-out Step Editor.

Pre-flight is the reminder text shown on the Fusor player's before you run this surface, and this field is the master copy every fusor draws from. When you add the action to a fusor's pre-run or post-run list, the fusor takes its own copy of this text at that moment. Editing Pre-flight here afterwards changes what a fusor copies the next time the action is added; fusors that already list the action keep the text they copied. To change the reminder on a fusor that already lists the action, edit its per-action override instead (see Pre-run Actions → per-action preflight editor).

This field edits the plain reminder only. A .faction file can also hold separate reminder text per DJ app; that stays a hand-edit in the file itself, and editing Pre-flight here leaves any per-app text already there untouched.

Both tabs read and write the same underlying .faction file. Edits in either tab show up in the other.

The Notes tab is where you rename an action, describe what it does, and tag which DJ apps it targets. The Code tab is where you author the steps themselves. For non-trivial edits, click the pencil to open the Step Editor.

What an action is, structurally

Every .faction file is a JSON document with a small fixed shape:

Action (.faction)
├── format: "faction"
├── version: 1
├── meta
│   ├── name              (display label)
│   ├── shortId           (REQUIRED: up to 12 characters, for controller
│   │                      and pad labels; an action without one won't run)
│   ├── description       (free-form summary)
│   ├── apps              (["traktor", "mixxx", …])
│   ├── actionId          (UUID, generated; do not hand-edit)
│   ├── preflight         (optional reminder shown before a run; edit the
│   │                      plain text on the Notes tab. Per-app entries
│   │                      stay a hand-edit)
│   └── anticipatedDurationMs   (optional override for the duration badge)
└── steps                 (ordered list, run top-to-bottom)

shortId is not optional. An action missing a valid one fails validation and will not run. The Step Editor exposes it as the Short ID field, and a file written by hand needs it too.

Steps come in six types: SET, WAIT, WAIT_UNTIL, CAPTURE, RESTORE, IF. The Step Editor walks through each one from the UI side.

Where files live

Actions are JSON files with the .faction extension, stored under your library folder (Documents/Fusor/ by default) in actions/:

<library>/
  actions/
    deck-prep.faction
    crossfader-bypass.faction
    fx-resets/
      reset-fx1.faction
      reset-fx2.faction

Subfolders are scanned, so an action filed into one still appears in the Actions list. They are for your own filing: the runtime treats every .faction file the same regardless of which folder it sits in.

The file name follows the action's name. Rename an action and the next save moves the file to match, staying in whatever subfolder you filed it in. The status line confirms it: "File renamed to match: filename." So the file on disk is findable by the name you see in the list.

A copy made outside Fusor Studio shares the original's identity. Duplicate an action in Explorer or Finder or let a sync tool leave a conflict copy behind, and both files show up in the Actions list, but only one of them is the action that packs actually point to: the original. The copy shows an orange duplicate mark. The original keeps its identity through renames made inside Fusor Studio and across restarts. When there's no original on record, such as the first time Fusor Studio sees the two files, or when the recorded original can no longer be found, the file with the plain, unmodified name is picked as the original instead. Renaming the original outside Fusor Studio while a copy exists is one way to trigger that: the next time the folder is scanned, the file with the plain name is picked as the original again. Deleting a copy clears its duplicate mark.

Nothing breaks when a file moves. Fusors reference an action by its id, so you can rename it, file it into a subfolder, or point Fusor Studio at a different library folder, and every fusor using that action keeps working. The one thing that does break a reference is deleting the action.

Packs work the same way. A pack is a separate .fpack file in the library's Packs/ folder, and it references actions by id too. Which folder an action lives in has no bearing on which packs it belongs to. See Pack Authoring for the 8-slot grid Pad Mode fires.

The authoring loop

To build an action:

Create or open the action in the Library window (right-click → Details, or + New Action).
Name and describe it on the Notes tab. Tag which DJ apps it targets so the list view filters correctly.
Author the steps. For quick changes, the Code tab is fine. For anything multi-step, click the pencil icon to open the Step Editor.
Assign it. Add the action to a fusor's Pre-run or Post-run list, drop it into a pad slot (Pack Authoring), or run it standalone from the Library for a one-shot test.
Iterate. Edits are written to disk as soon as they commit. Any fusor that already references the action uses the new version next time it runs, since there is one canonical file per action.

Nothing needs compiling and there is no separate test mode. What you save is what runs.

Editing while a fusor is running

The fusor detail view shows a save-lock banner while the loaded fusor is mid-transition (see Authoring Overview → Editing is paused mid-transition). Action authoring has no equivalent lock: Fusor Studio reads action files when the queue loads, so editing a .faction while a different fusor runs is safe.

If you edit an action that's currently in the pre-run queue of the loaded fusor, the change takes effect the next time the queue is loaded (typically the next time the fusor arms). The currently-running queue holds the version that was loaded when it armed.

Where to next

Action Editor: the pop-out Step Editor, the step list, per-type forms, address and value pickers.
Pack Authoring: group actions into an 8-slot pad-mode pack.
Pre-run Actions: wire actions into a fusor's pre-run and post-run lists.
Pad Mode: how packs and slots show up in the Fusor player.