Authoring Overview

Fusor Studio is a runtime and an editor. The runtime plays fusors; the editor lives inside the Library popover. What follows is how you open a fusor for editing, the mental model behind its automation, and the rhythm of building one. Each editing surface then has its own page later in the chapter.

Opening a fusor for editing

Editing happens in the Library popover, not the player. Open the Library from the menubar and switch to the Fusors tab. From there:

• Edit an existing fusor. Click the fusor's info icon (or right-click → Details) to open its detail view. The detail view is already editable. There's no separate "enter authoring" step.
• Create a new fusor. Click + at the top of the Fusors list. The new fusor opens directly in the popover as an unsaved draft (see Creating and duplicating below).
• Duplicate an existing fusor. Right-click a fusor in the picker and choose Duplicate. Type a name and the clone is written straight to your library and opens for editing.

Once a fusor has been saved at least once, there's no Save/Cancel bar and no pencil button. Edits commit as you make them (see Autosave below). A brand-new draft is the one exception: it keeps an explicit Save to library action until you save it for the first time.

Creating and duplicating

Clicking + opens a new fusor directly in the popover as an unsaved draft, with nothing yet written to disk. The Fusors list marks the row unsaved, and the detail view's subtitle reads Unsaved with a Save to library action in the header. There's no file-explorer dialog to fill in: when you click it, Fusor Studio derives the filename from the fusor's name and writes it into your library's fusors/ folder, adding a number if that name is already taken.

If the draft isn't valid yet (it has no domains, for example) Save fails with an explanation instead of losing your work (see When a save fails below). Closing the Library popover with an unsaved draft still open prompts Save / Discard / Cancel, whether you close from the in-app control or from Windows itself: Alt+F4, the taskbar close button, or quitting Fusor Studio.

Duplicate works the same way, minus the draft step. Right-click a fusor and choose Duplicate; an in-app prompt appears prefilled with "name copy". Confirm (or type a different name) and the copy is written directly into the library's fusors/ folder and appears in the list right away, with no file-explorer dialog. Duplicating the same fusor again auto-numbers the name: "name copy 2", and so on.

Autosave and undo

Every edit in the detail view writes to disk a fraction of a second after you commit it.

• Text fields (Name, Description, Author, Version, Your Notes) commit on blur: click out of the field or press Tab/Enter.
• Intent commits as you type. It's a textarea rather than a single-line field, so there's no Enter to press; the debounce below is what keeps that from churning the disk. Press Esc to release focus when you're done.
• Pickers (Mix-In Point, Apps) commit the moment you change the selection.
• Structural edits (add/delete a domain, add/delete an action, reassign an FX unit, change a curve anchor, toggle per-card preflight visibility) commit when you make them.

A debounced autosave (300 ms) batches rapid edits into a single write, so fast typing doesn't churn the disk.

If the fusor doesn't name any DJ apps yet, the save confirmation adds a reminder to tag them on the Info tab. Nothing about that reminder blocks or delays the save.

The detail view's tab bar carries an Undo button, sitting beside Info / Domains / Actions and tooltipped Undo last text edit (Ctrl/Cmd+Z). Clicking it (or pressing Ctrl+Z / Cmd+Z) reverses the most recent text-field edit in the detail view — name, description, notes, etc. The undo stack holds up to 50 edits and clears when you load a different fusor or close the popover.

Undo does not reverse structural edits. Adding or deleting a domain, adding or deleting an action, and changing curves on the Domain Editor surface are not in the text-undo stack. To reverse a deletion, re-add the domain or action from scratch. The per-card delete affordance asks you to confirm before it fires, so a misclick alone can't cost you a domain.

When a save fails

If a save can't complete, either because the fusor isn't valid yet or because the write itself fails, a persistent message reads "name not saved: reason". Your edits stay in the detail view exactly as you left them, so you can fix the problem and save again.

That message describes your last save attempt, and it stays until you make another one — it is not a live report on the fusor's current state. So if it named a problem and you then fix it, the message doesn't disappear on its own; it's replaced the next time a save runs. For a fusor already in your library that happens within a moment, because your edits save themselves. For a new fusor you haven't saved yet, nothing is written until you press Save to library, so the message waits there until you do.

Reopening a fusor always reflects what's actually on disk. If the file is corrupt or fails validation, the detail view shows a read error instead of pretending you have unsaved edits.

Editing is paused mid-transition

While the loaded fusor is mid-transition (running, paused, or in pre-run), the detail view shows an orange banner:

Fusor running — edits paused until the transition ends.

Text fields and add/delete affordances go read-only for the duration. The engine reads the fusor's structure live during a transition, so the lock prevents an in-flight write from corrupting that read. The banner clears automatically when the transition completes or aborts.

The lock applies only to the currently loaded fusor. Other fusors in the library remain editable throughout, so you can prep the next one while this one plays.

What a fusor is, structurally

Every fusor automates one transition: outgoing track fading out, incoming track fading in. The fusor's job is to drive a set of controls smoothly between the two states.

A fusor is structured as:

Fusor
├── Meta (name, app tags, …)
└── Domains
    ├── Domain (e.g. Incoming EQ)
    │   └── Parameter Bindings (one per parameter — Low, Mid, High)
    │       └── Curve (bezier anchors, or stepped step set)
    ├── Domain (e.g. Outgoing Volume)
    │   └── Parameter Bindings → Curve
    └── …

Three pieces to know:

For the canonical glossary entries, see Key Concepts. For every field the meta block can hold, see .fusor files.

Curves: continuous and stepped

A binding's curve is either continuous or stepped. The runtime treats the two differently and the editor offers different controls for each.

Continuous (the default)

Bezier curves with anchor points and tangent handles. The runtime evaluates the curve smoothly as the transition progresses, interpolating the value between anchors. Use continuous curves for any control that's musically continuous: volume, EQ, filter cutoff, FX wet/dry.

The Domain Editor's main surface is a side-by-side curve view. Drag anchors to reshape the curve; drag a handle to change its tangent.

Stepped (sample-and-hold)

The lane snaps to a small step set of named, discrete levels. The runtime holds the chosen value until the next anchor, with no interpolation. Use stepped curves for controls whose meaningful values are indexed: tempo range selectors, FX type choosers, delay-length-in-beats.

Click Attach… on the property strip below the canvas to flip a binding from continuous to stepped. A step set picker opens; pick from the bundled catalog or your own saved step sets and click Apply to this lane. A curve can also hold values with no step set attached, by setting the property strip's Interp control to Hold directly (see Curve Editor). Stepped Output has the full mechanics, the step set library, and a worked example.

Most bindings are continuous and stay that way.

Target scope: outgoing, incoming

Every binding has a target scope that tells the runtime which side of the transition it applies to:

• Outgoing. Drives the deck that's being mixed out.
• Incoming. Drives the deck that's being mixed in.

Scope is set when you create the domain (Add Domain → pick Both Sides, Outgoing Only, or Incoming Only). The role swap at transition completion is handled by the runtime. Your curves don't know which physical deck (A or B) they're driving, only the role.

Fusor parameter bindings are always tied to one side; there's no mixer-global ("shared") binding type today. Mixer-global addresses (e.g. crossfader, master tempo) are reached through actions.

The detail view tabs

The Fusor detail view exposes three tabs along the top:

Mix-In Point sits next to Author and Version, and says where the incoming track's mix-in point (the end of its intro) falls on the transition. There are three choices, and you can leave it unset:

It's advisory only: the engine never reads it to time anything, and "Middle" makes no claim about the halfway mark on the progress meter. It's there for you, or anyone you share the fusor with, to see at a glance what shape the transition has. The Fusors list shows it as a column, and you can sort by it: choose Mix-In in the list's Sort control and the fusors group start, then middle, then end, with unset ones last.

The loaded fusor gets a different, performance-oriented view of this same data: Session View, the inline panel opened by the info icon next to the picker. Rather than these three authoring tabs, it presents a single chronological stack (pre-run actions → domains → post-run actions) and is read-only apart from three small session-edit affordances. See Loading a fusor → Session View.

The authoring loop

The rhythm of building a fusor:

1. Open the fusor in the Library popover (click its info icon, or right-click → Details, or create a new one with +).
2. Add the domains you need. On the Domains tab, click Add Domain and pick a type, or Import Domain to copy a domain from another fusor in your library.
3. Edit curves. Click a domain card (or any parameter name inside it) to open the Domain Editor. Drag anchors to shape the curve. Toggle stepped output for discrete controls.
4. Wire up setup steps if the host needs them (engaging crossfader pass-through, switching FX banks, etc.) on the Actions tab → Pre-run.
5. Test on a transition. Load the fusor, arm, and fire against a pair of tracks; tweak; repeat. Edits to a non-loaded fusor land immediately; edits to the loaded fusor pause while it's mid-transition and resume when the transition ends.
6. Move on when the fusor feels right. Everything is already saved.

Where files live

Authored fusors are JSON files with the .fusor extension, stored flat in your library folder (Documents/Fusor/ by default) under fusors/:

<library>/
  fusors/
    house-to-techno.fusor
    breakdown-builder.fusor
    tight-cut.fusor

Keep them flat. Fusor Studio scans fusors/ itself and does not look inside subfolders, so a fusor you file into one will not appear in the picker or the Fusors list. Grouping is what collections are for: they're .fcollection files in the library's Collections/ folder that reference fusors by identity, so one fusor can belong to several collections without being copied anywhere.

The filename follows the fusor's name. When you rename a fusor in its detail view, Fusor Studio renames the file to match on the next save, adding a number if that filename is already taken. Renaming never breaks anything that points at the fusor. Each fusor carries a permanent internal identity, so collection membership survives the rename. If you share a .fusor file with another DJ, the filename and the name inside it will agree.

This also runs the other way: rename the .fusor file itself outside Fusor Studio and the next save renames it back to match the fusor's name, noting it on the status line. See Status Messages for what that notice means.

For the broader Library popover and where fusors appear in it, see Loading a fusor.

Where to next

• Domains — Add, import, and delete domains; per-card preflight; opening the Domain Editor.
• Pre-run Actions — Wire .faction actions into a fusor's Pre-run and Post-run lists; per-action preflight.
• FX Routing — Auto-assign FX units to decks and the Snapshot/Restore wrapper.
• Stepped Output — Author stepped lanes and the step set library.
• Curve Editor — Anchor drag, handles, interpolation, right-click copy/mirror, ghost overlays.
• Action Authoring Overview — Editing .faction files in the Library popover: Notes/Code tabs, autosave, create/duplicate/delete.
• Action Editor — Authoring action steps in the pop-out Step Editor.
• Pack Authoring — Group actions into an 8-slot pack for Pad Mode.
• Toolbox: Step Set Library — Build and manage stored step sets from the App menu, with no fusor open.
• Action File Reference — The .faction format for actions and pad-mode triggers.