Fusor File Reference (.fusor)

Fusor File Reference (.fusor)

A .fusor file is a JSON document holding one piece of automation: the domains it drives, the curve on each parameter, and the actions that run around it. It is what the player loads and what the Domain Editor writes.

This page is the reference for the format. For the editor that produces these files, see Authoring Overview. For the parameters a binding may target, see Supported Parameters.

You never have to write one by hand. Reading one is useful when you are sharing a fusor, comparing two versions, or working out why a file will not load.

File location and naming

Fusors live flat in your library's fusors/ folder, and the filename tracks the fusor's name. The folder rules, the renaming behavior, and how collections group fusors without moving files are covered in Authoring Overview → Where files live.

Top-level shape

{
  "version": "2.0",
  "meta": { ... },
  "domains": [ ... ],
  "actions": { ... }
}

Every level of the file rejects fields it does not recognize. A misspelled key fails the load, and the error carries the path it was found at.

Meta block

The apps list does more than label the file. It gates which domain types can be added to the fusor, and which fusors can be imported from. See Add Domain.

Domains

Each entry in domains is one control surface, on one or both sides of the transition.

{
  "domainTypeId": "eq",
  "instanceId": "eq_outgoing",
  "enabled": true,
  "bindings": [ ... ]
}

Most domains take their side from their bindings' addresses and need no role. FX Unit is the exception: its addresses carry no role prefix, so the domain has to say which deck it belongs to.

Preflight

"preflight": {
  "snapshot": { "default": "...", "traktor": "..." },
  "override": null,
  "hide": false
}

snapshot is a frozen copy of the domain type's reminder text, keyed by app with a default fallback. override replaces it when non-null. hide suppresses the reminder entirely. The editor for all three, and the order they resolve in, is in Domains → Per-card preflight.

Bindings

One binding is one automated parameter.

{
  "id": "out_volume_cos",
  "target": "outgoing.volume",
  "curve": { "anchors": [ ... ] }
}

A parameter with no curve is not written to the file, so a domain holds bindings only for the parameters you actually authored.

Curves

"curve": {
  "anchors": [ ... ],
  "stepValues": [ ... ]
}

Anchors

{
  "progress": 0.5,
  "value": 0.9,
  "handleIn":  { "dx": -0.2, "dy": 0 },
  "handleOut": { "dx":  0.2, "dy": 0 },
  "handleMode": "linked",
  "interp": "bezier"
}

An anchor with no handles is a plain bezier anchor with straight tangents. A two-anchor ramp usually carries none.

Step values

"stepValues": [
  { "label": "Off", "value": 0 },
  { "label": "On",  "value": 1 }
]

While stepValues is present, every segment holds regardless of what its anchor's interp says, and anchor values snap to one of the levels. The stored interp is left untouched and takes effect again if the step set is removed. The last anchor is also released from the usual "must end at 1.0" rule, because a stepped lane holds its final level to the end. See Stepped Output.

Actions block

"actions": {
  "before": [
    { "ref": "8f14e45f-ceea-467a-9a36-dedd4bea2543", "enabled": true }
  ],
  "after": []
}

before runs during pre-run, ahead of the automation. after runs once the transition completes.

Entry order is run order. An entry whose action is missing or invalid is skipped and reported rather than stranding the run — including one whose id no longer matches any action in the library, which is what you get if the action was deleted. For the runtime behavior of both lists, see Pre-run Actions; for the .faction format itself, see the Action File Reference.

Validation rules

A fusor is validated when it loads and again when it is saved. The rules beyond the field types above:

Structure

• version must be exactly "2.0".
• domains must hold at least one domain, and every domain at least one binding.
• Every instanceId must be unique within the file.
• domainTypeId must name a domain type that exists.
• An fx_unit domain must carry a role of incoming or outgoing and an fxUnitId from 1 to 4.
• A binding's target must be an address its own domain type owns. An EQ domain holding incoming.bogus.x fails validation, so it never reaches MIDI time and silently does nothing. This applies to role addresses (incoming.eq.low), unit-less FX addresses (fx.slot1.enable) and deck-pinned addresses (deck.a.eq.low) alike.
• A target that belongs to no domain type — a global such as mixer.crossfader — must name an address the canonical mapping defines. mixer.zzz is well-formed and means nothing, so it is rejected rather than accepted and left dead.
• Every entry in meta.apps must be a known app tag.

Curves

• Between 2 and 16 anchors.
• The first anchor must sit at progress: 0.
• The last anchor must sit at progress: 1, unless the curve carries stepValues.
• Anchor progress must strictly increase. Two anchors at the same progress are rejected.
• handleMode must be linked or independent; interp must be bezier, linear or hold.
• stepValues, when present, must hold 2 to 16 entries with a 1–32 character label and a value between 0 and 1.

A file that fails any of these does not load, and the error names the domain, binding and anchor it failed at. Nothing else changes when a fusor is refused: whatever was loaded stays loaded, and if it was armed it stays armed.

Worked example

The bundled Constant-Power Crossfade, in full. One Channel Fader domain with two sides — the file stores one domains entry per side, each with its own instanceId, and Studio groups them into a single row — each side carrying a binding whose two anchors and bezier handles approximate a cosine and a sine.

{
  "version": "2.0",
  "meta": {
    "name": "Constant-Power Crossfade",
    "author": "Fusor",
    "created": "2026-06-12T00:00:00Z",
    "description": "Canonical constant-power volume crossfade.",
    "apps": []
  },
  "domains": [
    {
      "domainTypeId": "volume",
      "instanceId": "vol_outgoing",
      "enabled": true,
      "bindings": [
        {
          "id": "out_volume_cos",
          "target": "outgoing.volume",
          "curve": {
            "anchors": [
              { "progress": 0.0, "value": 1.0, "handleOut": { "dx": 0.4477, "dy": 0.0 } },
              { "progress": 1.0, "value": 0.0, "handleIn": { "dx": -0.4477, "dy": 0.5523 } }
            ]
          }
        }
      ]
    },
    {
      "domainTypeId": "volume",
      "instanceId": "vol_incoming",
      "enabled": true,
      "bindings": [
        {
          "id": "in_volume_sin",
          "target": "incoming.volume",
          "curve": {
            "anchors": [
              { "progress": 0.0, "value": 0.0, "handleOut": { "dx": 0.4477, "dy": 0.5523 } },
              { "progress": 1.0, "value": 1.0, "handleIn": { "dx": -0.4477, "dy": 0.0 } }
            ]
          }
        }
      ]
    }
  ]
}

"apps": [] makes it universal, so it is offered on every DJ app. Neither domain declares a role, because the binding addresses already say which side each drives.