Status Messages

The status line at the bottom of the player is where Fusor Studio tells you what it just did, or why it just refused to do something. It has room for about forty characters, so warnings and errors carry a code, and the code is what brings you here.

Reading a status message

A warning or an error is prefixed with its code:

CAP5-Uncaptured: run Capture first
└──┘
 code

Look the code up below. Confirmations and progress notes carry no code; there is nothing to fix.

The colour tells you the severity, and how long the message stays on screen:

ColourMeaningOn screen for
RedError — Fusor Studio refused to do something, or stopped doing it12 seconds
OrangeWarning — Fusor Studio carried on, but not the way you asked12 seconds
GreenSuccess — something finished4 seconds
GreyInformation — something is happening4 seconds

Some codes also disable a button. Where they do, it is noted below, and hovering the disabled button tells you the same thing this page does. The rest are status-line-only: this page is the only place they are explained.

Messages that quote a control name shorten it to its last two segments (eq.high, filter.resonance) and always refer to the deck the message is about. The full address is in main.log (Logging).


Control State Capture — CAP1–CAP8

Control State Capture reads the current position of every control in the DJ app and stores it as a baseline. Fusor Studio needs it to know where a transition starts from, and to put the controls back afterwards. It runs at startup and can be re-run from Settings.

CAP1 — Capture deferred until idle

CAP1-Capture deferred until idle

What it means. A Control State Capture was requested while a transition was armed or running. Capture resets deck roles, so it never runs mid-transition. It stays queued and runs by itself as soon as the player returns to idle.

What to do. Nothing. Finish, abort, or disarm the transition and the capture runs on its own.

CAP2 — No DJ app: set one in Settings

CAP2-No DJ app: set one in Settings

What it means. No DJ app is designated, so there is nothing to capture from and no control baseline exists. Fusor Studio will not arm a transition without one.

What to do. Choose your DJ app in Settings → Connection, then re-run Capture.

Fusor Studio does not pick a mode for you here. It reports that there is no baseline and leaves the decision to you.

CAP3 — Capture failed: see Settings

CAP3-Capture failed: see Settings

What it means. Capture ran and did not complete. Fusor Studio has no baseline of the DJ app's control positions.

What to do. Open Settings → Connection and run Capture again. If it keeps failing, the MIDI return path is the usual cause (see Troubleshooting).

CAP4 — Capture skipped: run Capture

CAP4-Capture skipped: run Capture

Disables the Arm button while it applies. Hovering shows the same explanation as below.

What it means. A capture was offered and declined, so there is no baseline. Fusor Studio will not arm or start a transition without one.

What to do. Control State Capture was declined. Fusor Studio won't arm or start a transition without a baseline of the DJ app's current control positions; without it, it can't restore them afterwards. Run Capture from Settings. Capture needs a DJ app designated there first.

CAP5 — Uncaptured: run Capture first

CAP5-Uncaptured: run Capture first

Disables the Arm button while it applies. Hovering shows the same explanation as below.

What it means. Capture has never run in this session, so there is no baseline. Fusor Studio will not arm or start a transition without one.

What to do. Control State Capture hasn't run. Fusor Studio won't arm or start a transition without a baseline of the DJ app's current control positions; without it, it can't restore them afterwards. Run Capture from Settings. Capture needs a DJ app designated there first.

CAP6 — Capture failed: no telemetry

CAP6-Capture failed: no telemetry

What it means. Fusor Studio asked the DJ app for its control positions and heard nothing back at all, so there is no baseline and arming stays blocked.

What to do. It usually means the MIDI bus is not connected in both directions: Fusor Studio is sending, but nothing is coming back. Check that the DJ app's MIDI output is routed to the same port Fusor Studio listens on, and that its mapping declares output (feedback) messages and not just input. See MIDI Mapping and Troubleshooting. Re-run Capture from Settings once the return path works. If you want to run without telemetry anyway, turn on Blind Mode from the App menu.

Running blind is your choice, not one the app makes for you. A failed capture reports the problem and changes nothing about how Fusor Studio behaves.

CAP7 — Capture failed: no deck state

CAP7-Capture failed: no deck state

What it means. Some telemetry arrived, but the DJ app never reported whether its decks are playing, so Fusor Studio cannot tell which deck is which and arming stays blocked.

What to do. Typically the mapping sends control positions but not deck state. Add the deck play-state feedback rows to the DJ app's mapping (see MIDI Mapping), then re-run Capture from Settings. If you want to run without telemetry anyway, turn on Blind Mode from the App menu.

CAP8 — Blind Mode on: capture skipped

CAP8-Blind Mode on: capture skipped

What it means. A capture was requested while Blind Mode is on. Blind Mode ignores everything the DJ app sends back, so there is nothing for a capture to observe. Fusor Studio is running on a default baseline.

What to do. Turn Blind Mode off (App menu) to capture the app's real control positions. Fusor Studio runs a capture automatically when you do.


Start and Play — GATE1–GATE5

A transition mixes out of one playing deck and into another. Most of these fire when that is not true yet.

GATE5 is the exception, and it is not about the decks at all: the press was simply early. The pre-run queue is still setting up, so there is no run to pause. The button shows PAUSE throughout — it is showing you what it will do once the run starts, not promising it will work now.

GATE1 — Not ready: outgoing not playing

GATE1-Not ready: outgoing not playing

What it means. The outgoing deck is not playing, so the transition is not ready to run. A transition mixes out of that deck.

What to do. Start the outgoing deck in the DJ app. Fusor Studio picks the change up on its own; you do not need to re-arm.

GATE2 — Start: outgoing not playing

GATE2-Start: outgoing not playing

Disables the Play button while it applies. Hovering shows the same explanation as below.

What it means. Play was pressed while the outgoing deck is stopped.

What to do. A transition mixes out of the outgoing deck, so that deck has to be playing before it can start. Start the outgoing deck in the DJ app.

GATE3 — Play: incoming not playing

GATE3-Play: incoming not playing

Disables the Play button while it applies. Hovering shows the same explanation as below.

What it means. Play was pressed while the incoming deck is stopped.

What to do. A transition mixes into the incoming deck, so that deck has to be playing before it can start. Start the incoming deck in the DJ app.

GATE4 — No fusor loaded

GATE4-No fusor loaded

Disables the Arm button while it applies. Hovering shows the same explanation as below.

What it means. Arm or Play was pressed with no fusor loaded in the player.

What to do. Nothing is loaded in the player, so there is nothing to arm or start. Load a fusor first.

GATE5 — Pre-run setup: can't pause yet

GATE5-Pre-run setup: can't pause yet

What it means. Pause was pressed while the pre-run queue was still running. The transition has not started yet, so there is nothing to pause — the button shows PAUSE because that is what it will do once the run begins.

What to do. Wait. The pre-run queue finishes on its own and the transition starts, after which Pause works normally. If you would rather not run it at all, press Abort — that does work during pre-run, and it undoes any setup the queue had already done.

Pressing Pause here changes nothing: the pre-run queue is not interrupted, and the transition still starts when it finishes. The button flashes red to tell you the press was received and refused, rather than missed.


Run Mode — MODE1–MODE6

The Auto/Manual toggle chooses what drives the progress meter: time (Auto) or the crossfader (Manual).

MODE1 — Manual Run Mode: Blind Mode

MODE1-Manual Run Mode: Blind Mode

Disables the Auto/Manual toggle while it applies. Hovering shows the same explanation as below.

What it means. Manual Run Mode was selected in Blind Mode. Manual progress follows the crossfader, which Fusor Studio tracks through telemetry, and Blind Mode ignores telemetry.

What to do. Manual Run Mode is driven by an actuator Fusor Studio tracks through telemetry. Blind Mode ignores telemetry, so progress can only be time-driven (Auto Run Mode).

Blind Mode is off at every launch, so this only appears if you turned it on in this session.

MODE2 — Mode locked: transition active

MODE2-Mode locked: transition active

Disables the Auto/Manual toggle while it applies. Hovering shows the same explanation as below.

What it means. The Auto/Manual toggle was pressed during a running transition.

What to do. The progress source can't change while a transition is running, because switching mid-run would jump the progress meter. Abort or finish the transition first.

This is not the same as manual takeover. To take a running transition over by hand, grab the crossfader (see Manual Run Mode vs Auto Run Mode).

MODE3 — Blind Mode: switched to Auto

MODE3-Blind Mode: switched to Auto

What it means. Blind Mode was turned on while Manual Run Mode was selected, so the run mode switched to Auto Run Mode. Manual Run Mode needs telemetry to follow the crossfader; Blind Mode ignores telemetry.

What to do. Nothing is required; the transition will run time-driven. To get Manual Run Mode back, turn Blind Mode off.

MODE4 — Blind Mode off: MIDI bus changed

MODE4-Blind Mode off: MIDI bus changed

What it means. You changed the MIDI bus while Blind Mode was on, so Fusor Studio rebuilt its connection to your DJ app and turned Blind Mode off with it. Blind Mode is a decision about one particular setup; once the bus changes, Fusor Studio goes back to listening rather than assuming the new one is deaf too.

What to do. Nothing is required; a capture runs straight away on the new bus. If your DJ app sends no telemetry, that capture will fail and offer you Blind Mode again; you can also turn it back on from the App menu at any time.

MODE5 — Demo: Auto Run Mode only

MODE5-Demo: Auto Run Mode only

Disables the Auto/Manual toggle while it applies. Hovering shows the same explanation as below.

What it means. Manual Run Mode was selected while Fusor Studio is running unlicensed, in Demo. Demo runs every transition on the clock, so the progress meter is time-driven and the crossfader stays under Fusor Studio's control.

What to do. Demo runs transitions on the clock so you can see how they work. Manual Run Mode needs a license.

Demo exists so you can watch how a transition works, not to mix on. A license unlocks Manual Run Mode.

MODE6 — Demo: crossfader stays automated

MODE6-Demo: crossfader stays automated

What it means. You moved the crossfader during a running transition in Demo. Demo does not hand the transition over, so Fusor Studio kept driving the fader from the clock and your movement was overwritten on the next tick. That is why the fader sprang back.

What to do. Nothing is wrong; the transition is still running and will finish on its own. Press Abort if you want to stop it and watch it again from the start. To take a transition over by hand, you need a license.

The spring-back is Demo behaving as designed, not a MIDI problem.


Start-with-Incoming — SWI1–SWI3

Start-with-Incoming hands the start trigger to the incoming deck: instead of pressing Play, you start the deck in the DJ app and the transition begins when Fusor Studio sees it playing. These all fire on a hardware button press; the on-screen toggle disables itself instead.

SWI1 — Start-with-Incoming blocked

SWI1-Start-with-Incoming blocked

Disables the Start-with-Incoming toggle while it applies. Hovering shows the same explanation as below.

What it means. Start-with-Incoming was toggled during a running transition. It decides how a transition begins, so it is fixed once one is under way.

What to do. Start-with-Incoming can't be changed while a transition is active. It decides how the transition begins, so it's fixed once one is under way.

SWI2 — Start-with-Incoming blocked

SWI2-Start-with-Incoming blocked

Disables the Start-with-Incoming toggle while it applies. Hovering shows the same explanation as below.

What it means. Start-with-Incoming was toggled in Blind Mode. The trigger is Fusor Studio seeing the incoming deck start playing, and Blind Mode ignores telemetry, so there is nothing to see it with.

What to do. Start-with-Incoming begins the transition when Fusor Studio sees the incoming deck start playing. Blind Mode ignores telemetry, so there is nothing to see.

Press Play to start the transition by hand while Blind Mode is on.

SWI3 — Start-with-Incoming blocked

SWI3-Start-with-Incoming blocked

Disables the Start-with-Incoming toggle while it applies. Hovering shows the same explanation as below.

What it means. Start-with-Incoming was toggled while the incoming deck is already playing. There is no start left to wait for.

What to do. The incoming deck is already playing, so Fusor Studio can't wait for it to start. Press Play to start the transition now, or stop the incoming deck first.


Tempo Ramp — TR1–TR8

The tempo ramp moves the incoming deck to the outgoing deck's tempo before the transition starts, so the two tracks are already matched when the mix begins. It is app-specific and needs telemetry to confirm it landed.

TR1 — Tempo ramp: transition active

TR1-Tempo ramp: transition active

Disables the Tempo Ramp toggle (arming it; disarming stays available) while it applies. Hovering shows the same explanation as below.

What it means. The tempo ramp was armed during a running transition. It can only be armed before one starts.

What to do. The tempo ramp can only be armed before a transition starts. It moves the incoming deck's tempo to meet the outgoing deck's, which would be audible mid-transition.

TR2 — Tempo ramp: Blind Mode

TR2-Tempo ramp: Blind Mode

Disables the Tempo Ramp toggle (arming it; disarming stays available) while it applies. Hovering shows the same explanation as below.

What it means. The tempo ramp was armed in Blind Mode. It needs telemetry to confirm the deck actually reached the target tempo, and Blind Mode ignores telemetry.

What to do. The tempo ramp needs telemetry to confirm the deck reached its target tempo. Blind Mode ignores telemetry, so the ramp can't run.

TR3 — Tempo ramp: incoming audible

TR3-Tempo ramp: incoming audible

What it means. The tempo ramp was armed while the incoming deck may be audible: it is playing and its level is up. The ramp moves that deck's tempo, which the audience would hear.

What to do. Bring the incoming deck's fader down (or its crossfader side across), then arm the ramp again.

This one is judged the moment you press it, based on where the faders are right now. The Tempo Ramp toggle stays enabled and refuses the press rather than greying itself out, because a toggle that flickered in and out of reach as you touched the mixer would be harder to read than a clear refusal.

TR4 — Tempo ramp: no routine for DJ app

TR4-Tempo ramp: no routine for DJ app

Disables the Tempo Ramp toggle (arming it; disarming stays available) while it applies. Hovering shows the same explanation as below.

What it means. The designated DJ app has no tempo ramp routine. Routines are app-specific; Traktor has one.

What to do. No tempo ramp routine exists for the designated DJ app, so the ramp cannot arm. Routines are app-specific (Traktor has one); check Settings → Connection, or run without a tempo ramp.

TR5 — Tempo ramp late: may be audible

TR5-Tempo ramp late: may be audible

What it means. The tempo ramp started after the transition was already under way, so the tempo change may be audible. It runs anyway; the timing of the ramp itself is unchanged.

What to do. Nothing mid-transition. To avoid it next time, arm the tempo ramp before starting, and give the pre-run actions time to finish before the incoming deck starts.

TR6 — Tempo ramp skipped: {reason}

TR6-Tempo ramp skipped: tempo range set…

What it means. The tempo ramp did not run. The reason comes from the ramp routine and is quoted on the status line; the full text is in the log.

What to do. Check main.log for the untruncated reason (see Logging). The transition itself is unaffected; the decks are simply not tempo-matched by Fusor Studio.

TR7 — Tempo ramp error: {reason}

TR7-Tempo ramp error: no response from …

What it means. The tempo ramp routine threw an error. The message is quoted from the routine; the full text is in the log.

What to do. Check main.log for the untruncated error (see Logging).

TR8 — {deck} ±{n}%: fader pinned

TR8-Deck B ±6%: fader pinned

What it means. The tempo ramp finished and put the deck's tempo range back the way it found it. At the tempo the deck is now playing, though, that range leaves the tempo fader pinned at the end of its travel. The tempo is correct; the fader has no room left to move in that direction.

What to do. Widen the deck's tempo range in the DJ app, which frees the fader without changing the tempo. To stop it happening again, set Tempo range restore to Keep usable in Settings → General. Fusor Studio then leaves the range wide enough to be usable instead of restoring it exactly.


Actions — ACT1–ACT12

Actions are .faction files that run before a transition (the pre-run queue), after it (the post-run queue), or on a controller button. Read the code, not just the words: ACT1, ACT3, ACT4, ACT9 and ACT10 mean Fusor Studio logged the failure and carried on. ACT2, ACT7, ACT8, ACT11 and ACT12 mean it stopped. The status line has no room to say so.

The split follows the run mode. In Auto Run Mode Fusor Studio owns the timing, so a failed pre-run action stops the transition before it starts (ACT2, ACT8, ACT11 and ACT12). In Manual Run Mode your hand is already on the crossfader, and that gesture is what starts the run, so Fusor Studio reports the failure and follows the fader (ACT1 and ACT9) rather than refusing to move.

ACT1 — Prerun failed: {id}

ACT1-Prerun failed: ResetInEQ

What it means. A pre-run action failed in Manual Run Mode. The transition started anyway. You are driving, so Fusor Studio does not take the decision to abort out of your hands. Whatever that action was meant to set up (FX routing, a control reset) has not been set up.

What to do. Decide on the spot: the transition is running and you have the crossfader. Afterwards, check main.log for why the action failed (see Logging), and test it from the Action Editor.

ACT2 — Prerun aborted: {id}

ACT2-Prerun aborted: RouteFX_A

What it means. A pre-run action failed in Auto Run Mode. The transition did not start. The player is back to Armed.

What to do. Check main.log for why the action failed (see Logging) and fix it in the Action Editor. To run the transition without it, remove the action from the fusor's pre-run list, or switch to Manual Run Mode, which continues past a failed pre-run action (ACT1) instead of stopping.

ACT3 — Postrun timed out: stopped

ACT3-Postrun timed out: stopped

What it means. The post-run queue ran past its 5-second cap. The remaining post-run actions were skipped. The transition itself completed normally.

What to do. Put anything the skipped actions were meant to tidy up back by hand, and shorten the queue: the cap covers all post-run actions together.

ACT4 — Postrun failed: {id}

ACT4-Postrun failed: ClearFX

What it means. A post-run action failed. The transition itself completed normally. Post-run actions run after it is over, so a failure here cannot affect the mix. Whatever the action was meant to tidy up (restoring a control, clearing FX) has not been tidied up.

What to do. Check main.log for why it failed (see Logging), and put the affected controls back by hand if needed.

ACT7 — Action error: {reason}

ACT7-Action error: ENOENT: no such file

What it means. An action threw an error rather than reporting failure: an unreadable file, a bad address, a step that could not be executed. The message is quoted from the error; the full text is in the log.

What to do. Check main.log for the untruncated error (see Logging).

ACT8 — Prerun timed out: aborted

ACT8-Prerun timed out: aborted

What it means. The pre-run queue ran past its 5-second cap in Auto Run Mode. The remaining actions were skipped and the transition did not start. The player is back to Armed.

What to do. Shorten the queue: the cap covers all pre-run actions together, and a WAIT step spends it fastest. See Pre-run Actions. Then press Play again.

ACT9 — Prerun timed out: continued

ACT9-Prerun timed out: continued

What it means. The pre-run queue ran past its 5-second cap in Manual Run Mode. The remaining actions were skipped and the transition started anyway. You are already moving the crossfader, and that is what starts a manual run. Whatever the skipped actions were meant to set up (FX routing, a control reset) has not been set up.

What to do. Decide on the spot: the transition is running and you have the crossfader. Afterwards, shorten the queue: the cap covers all pre-run actions together, and a WAIT step spends it fastest. See Pre-run Actions.

ACT10 — Action skipped: {id}

ACT10-Action skipped: RouteFX_A

What it means. A pre-run or post-run action could not be loaded, so it never ran. Either its .faction file could not be read (moved, renamed, or deleted outside Fusor Studio) or it failed validation. The transition itself was unaffected and ran normally; whatever the action was meant to set up or tidy up has not been.

What to do. Open the action in the Action Editor: it reports what is wrong. To run the transition without it, remove the action from the fusor's pre-run or post-run list in Session Details.

The library lists an action by its name and description and does not check its steps, so a broken action looks perfectly normal there. Loading it for a run is what finds this. If more than one action was skipped, the status line names the first and main.log names them all, with the reason for each (see Logging).

ACT11 — Prerun ~{ms}ms over 5s: aborted

ACT11-Prerun ~6080ms over 5s: aborted

What it means. The pre-run actions for this fusor already add up to more than the 5-second cap, so in Auto Run Mode the transition did not start and none of them ran. The player is back to Armed. This is the same ceiling as ACT8, applied before the queue starts rather than part-way through it — Fusor refuses at once instead of making you wait out a delay it has already decided not to allow.

What to do. Shorten the queue: the cap covers all pre-run actions together, and a WAIT step spends it fastest. Disabling one action is often enough — the total shown on the fusor's pre-run list is the figure being measured. See Pre-run Actions. Then press Play again.

ACT12 — Prerun over run length: aborted

ACT12-Prerun over run length: aborted

What it means. The pre-run actions for this fusor add up to at least as long as the transition itself, so in Auto Run Mode the transition did not start and none of them ran. The player is back to Armed. This is a different ceiling from ACT8 and ACT11: those measure the queue against the 5-second cap, this one measures it against the length of your transition. A queue can be inside the cap and still be too long for a short transition — 4 bars at 128 BPM lasts 7.5 seconds.

What to do. Either shorten the pre-run queue, or give the transition more bars to run over. Fusor refuses rather than starting, because a transition with no time left cannot sweep from the beginning to the end — and it will not skip the beginning to fit. See Pre-run Actions, then press Play again.

Manual Run Mode never produces this message. There the crossfader is what drives progress, so a slow pre-run costs the transition nothing — it simply starts once the queue is done.


Controls — CTL1–CTL7

These concern individual controls rather than the transition as a whole. Where a control is named, it is left exactly where you put it. Fusor Studio declines to move it. It does not reset it, and it does not adjust it to compensate. The rest of the transition runs normally.

The two restore codes are the exception, and they report the opposite situation: Fusor Studio did send controls somewhere, and could not confirm they arrived.

CTL1 — Incoming {addr} mismatch

CTL1-Incoming eq.high mismatch

What it means. A control on the incoming deck is too far from where the fusor expects to start. Automating it would jump the control audibly, so Fusor Studio leaves it alone for the whole transition. Everything else runs.

What to do. Before arming, set the named control on the incoming deck to the value the fusor starts from, usually center for an EQ. Then re-arm.

The address is shortened to its last two segments: eq.high is the incoming deck's high EQ.

CTL2 — {n} parameters: value mismatch

CTL2-3 parameters: value mismatch

What it means. Several incoming-deck controls are too far from where the fusor expects to start. Fusor Studio leaves all of them alone for the whole transition. The rest of it runs.

What to do. Check main.log for which controls (see Logging), set them where the fusor starts from, usually center for EQs, and re-arm.

CTL3 — Restore sent ({n}): unconfirmed

CTL3-Restore sent (12): unconfirmed

What it means. The transition finished and Fusor Studio sent the outgoing deck's controls back to where they were before it started, but no telemetry came back to confirm they landed. The messages were sent; whether the DJ app acted on them is unknown.

What to do. Look at the outgoing deck in the DJ app and put anything that did not move back by hand. If it happens every time, the MIDI return path is the cause (see Troubleshooting).

CTL4 — {addr} off-curve

CTL4-filter.resonance off-curve

What it means. The named control is set-and-hold in this fusor, one value held for the whole transition, and the deck is not at that value. Moving it there would jump the control audibly instead of fading it, so Fusor Studio leaves the control alone. The rest of the transition runs.

What to do. Set the control to the value the fusor holds it at before arming. Fusor Studio will then drive it.

CTL5 — {addr} past end

CTL5-eq.low past end

What it means. The named control is already past the value the fusor's curve ends on, so there is nothing left for the curve to do except pull the control backwards. Fusor Studio leaves it alone. The rest of the transition runs.

What to do. Set the control back within the range the curve travels before arming. For a fade-out, that means back up toward its starting value.

CTL6 — Manual takeover: {addr}

CTL6-Manual takeover: eq.mid

What it means. You moved a control Fusor Studio was driving. Fusor Studio released that one control to you for the rest of the transition and stopped sending to it. It also dropped it from the restore snapshot, so it will not be put back at the end. Where you leave it is where it stays. The rest of the transition keeps running.

What to do. Nothing. To put the control back under automation, abort and re-arm.

This is per-control. Grabbing the crossfader is different: that takes the whole transition over. See Manual Run Mode vs Auto Run Mode.

CTL7 — Pre-run restore sent: unconfirmed

CTL7-Pre-run restore sent: unconfirmed

What it means. You pressed RESTORE after an abort — or Fusor Studio unwound a pre-run setup for you — and it sent the controls back to where they were before the run, but no telemetry came back to confirm they landed. The messages were sent; whether the DJ app acted on them is unknown. In Blind Mode it is always unknown, because Blind Mode ignores everything the DJ app sends back.

What to do. Look at the mixer in the DJ app and put anything that did not move back by hand. If it happens every time and you are not in Blind Mode, the MIDI return path is the cause (see Troubleshooting).


Pads — PAD1–PAD5

The eight pads trigger actions from the active pack. PAD1 to PAD4 fire when a pressed pad has nothing it can run; PAD5 fires when the action ran and failed.

PAD1 — {pad}: no active pack

PAD1-Pad 3: no active pack

On screen. The eight pads are replaced by a single "No active pack" panel, and hovering it explains why. The message fires when you press a pad on the controller.

What it means. A pad was pressed with no pack active, so there is nothing bound to any of the eight pads.

What to do. No pad pack is active. Open the Library, go to Actions → Packs, right-click a pack and choose Set Active.

PAD2 — {pad}: pack not found

PAD2-Pad 3: pack not found

What it means. A pad was pressed and the active pack's .fpack file could not be found. It has usually been moved, renamed, or deleted outside Fusor Studio.

What to do. The active pad pack file is missing. Open the Library, go to Actions → Packs, and set an existing pack active.

PAD3 — {pad}: empty slot

PAD3-Pad 5: empty slot

On screen. The pad is greyed, and hovering it explains why. The message fires when you press it on the controller.

What it means. A pad was pressed and its slot in the active pack is empty.

What to do. This pad has no action bound to it. Open the Library, go to Actions → Packs, right-click the active pack and choose Edit Pad Slots.

PAD4 — {pad}: action invalid

PAD4-Pad 2: action invalid

What it means. A pad was pressed and the action bound to it failed validation, so it did not run.

What to do. The action bound to this pad failed validation and won't run. Open it in the Action Editor to see why.

The pad looks normal until you press it. Fusor Studio only finds this out at press time, because it has to read and validate the .faction file to know, so unlike an empty slot it cannot grey the pad out in advance.

PAD5 — {pad}: {reason}

PAD5-Pad 7: unknown address

What it means. A pad's action threw an error. The message is quoted from the error; the full text is in the log.

What to do. Check main.log for the untruncated error (see Logging), then test the action from the Action Editor.


Hardware Controller — HW1–HW2

Fusor Studio watches the MIDI port your hardware controller is connected on. These messages fire when that port goes away mid-session (an unplugged cable, a controller powered off, a USB hub dropping out), when it comes back, and when a saved controller profile is active at startup but its port is not there at all. They concern the controller that drives Fusor Studio, not any controller you have connected to the DJ app.

HW1 — Controller disconnected: {port}

HW1-Controller disconnected: LPD8 mk2

What it means. The MIDI port your hardware controller was connected on has disappeared, so Fusor Studio closed it. Buttons, pads and faders on that controller do nothing until it comes back. Nothing else is affected: a transition in progress keeps running, and the on-screen controls still work.

What to do. Check the controller's USB cable and power. Fusor Studio keeps watching for the port and re-attaches on its own when it returns (HW1 is followed by "Controller reconnected"). If the controller is plugged in and the message persists, unplug and replug it. A port that reappears under a different name has to be re-selected in Settings → Input Mapping.

HW2 — Controller not connected: {port}

HW2-Controller not connected: LPD8 mk2

What it means. A controller profile is active, but the MIDI port it expects is not there, so the controller was never connected this session. This is the startup counterpart to HW1: HW1 means a controller that was working went away, HW2 means one was expected and never arrived. Fusor Studio keeps watching for the port and attaches on its own if it appears. Nothing else is affected; the on-screen controls all work normally.

What to do. Your active controller appears to not be connected. Consider deactivating the controller in Settings → Input Mapping, or checking the connection.


Both Decks Stopped — RUN1–RUN3

A transition needs at least one deck playing. These messages fire when Fusor Studio sees that neither is: you stopped both, or both ran out.

What happens next depends on how far the transition had got, and the code tells you which. RUN1 means the run had not started yet — it was still setting up — so there was nothing to hold and Fusor Studio abandoned it, disarmed, and undid the setup for you. RUN3 means the run was already under way, so it pauses and waits instead of ending: start the incoming deck again and the transition picks up where it left off.

Neither one moves a control by itself. Where the controls were when the decks stopped is where they stay.

In Manual Run Mode a run that has already started does neither. The crossfader drives the transition and your hand is still on it, so what the decks are doing changes nothing: no pause, no message, and the transition keeps following the fader. RUN1 still fires, because setup runs the same way in both modes.

RUN1 — Both decks stopped: aborted

RUN1-Both decks stopped: aborted

What it means. Both decks stopped while the pre-run queue was still setting up, so the transition never started. Fusor Studio cancelled the queue and disarmed.

What to do. Nothing is broken. Start a deck and re-arm. Nothing was mixed, so if the pre-run queue had already routed FX or reassigned the crossfader, Fusor Studio undoes that for you — you see "Pre-run setup unwound" when it does.

The undo runs by itself here, without asking, because nothing had been mixed and nothing is audible. That is only true before a run starts. Once one has, both decks stopping pauses it instead — see RUN3.

RUN3 — Both decks stopped: paused

RUN3-Both decks stopped: paused

What it means. Both decks stopped part-way through a transition, so Fusor Studio paused it. The run is not over. The meter holds where it had reached, the player stays armed, and every control the transition was driving stays exactly where the automation last put it — EQs part-swept, faders mid-travel, FX still engaged.

What to do. Start the incoming deck again and the transition resumes on its own, from where it stopped. If you would rather not finish it, hold Abort: the run ends and the Abort button becomes RESTORE, which puts the controls back the way they were before the run.

The pause has no time limit and nothing else releases it. Fusor Studio keeps hold of the controls it was driving for as long as it lasts, so if you have moved on from this transition, abort it rather than leaving it paused. It is the incoming deck specifically that resumes it; restarting the outgoing deck alone does not.


Session — SES2–SES6

A fusor can drive controls your DJ app does not have. These messages fire when Fusor Studio switches those domains off as the fusor loads, rather than send to controls that cannot respond.

The decision is yours to reverse. Every domain it switches off can be switched back on with its own toggle, and it names the control that caused it. Fusor Studio works this out again on every load and whenever you change your DJ app; it never writes it into the fusor file, and it never overrides a domain you switched off yourself. What it knows about each app is in Settings, under App Compatibility.

SES2 — {n} domains off: not in {app}

SES2-2 domains off: not in Traktor

What it means. The fusor you loaded drives controls your DJ app does not have, so Fusor Studio switched those domains off for this run rather than sending to controls that cannot respond. The rest of the fusor is untouched and runs normally.

What to do. Nothing, if the fusor still does what you want without them — open Session View to see which domains went off and why. Each one names the control that caused it. If you disagree, switch the domain back on with its toggle: the decision is yours and it holds for this run. What Fusor Studio knows about each app lives in Settings, under App Compatibility.

This is undone and worked out again every time you load a fusor, and again whenever you change your DJ app in Settings. It is never saved into the fusor file, and it never overrides a domain you switched off yourself.

SES3 — {n} domains off: nothing specific

SES3-3 domains off: nothing specific

What it means. The same as SES2, but nothing that is specific to a DJ application survived. Every domain still running is one Fusor Studio has no record of any application lacking. That is not the same as "works everywhere" — for most applications those records are still empty. What went off is everything Fusor Studio has a record of some application lacking.

What to do. Open Session View to see what went off and why, and switch a domain back on with its toggle if you want it to run anyway. If the fusor was written for a different DJ application, another fusor is likely the better answer than overriding this one.

SES4 — {n} domain off: not in {app}

SES4-1 domain off: not in Traktor

What it means. SES2 with a single domain. The fusor you loaded drives a control your DJ app does not have, so Fusor Studio switched that domain off for this run rather than sending to a control that cannot respond. The rest of the fusor is untouched and runs normally.

What to do. Nothing, if the fusor still does what you want without it — open Session View to see which domain went off and why. It names the control that caused it. If you disagree, switch the domain back on with its toggle: the decision is yours and it holds for this run. What Fusor Studio knows about each app lives in Settings, under App Compatibility.

This is undone and worked out again every time you load a fusor, and again whenever you change your DJ app in Settings. It is never saved into the fusor file, and it never overrides a domain you switched off yourself.

SES5 — {n} domain off: nothing specific

SES5-1 domain off: nothing specific

What it means. SES3 with a single domain: one domain went off, and nothing that is specific to a DJ application is left running. Every domain still going is one Fusor Studio has no record of any application lacking, which is not the same as "works everywhere" — for most applications those records are still empty.

What to do. Open Session View to see what went off and why, and switch the domain back on with its toggle if you want it to run anyway. If the fusor was written for a different DJ application, another fusor is likely the better answer than overriding this one.

SES6 — Fusor unloaded: reload failed

SES6-Fusor unloaded: reload failed

What it means. You changed a setting that rebuilds the engine — the MIDI bus, the DJ app, or the deck layout — and Fusor Studio could not put your fusor back afterwards. Normally the rebuild is invisible and your fusor stays loaded. This fires when the reload was refused: usually the file has been renamed, moved or deleted since you loaded it, or you switched to a DJ app that does not have controls the fusor drives. Nothing is loaded now.

What to do. Load the fusor again from the library. If it will not load, open it in the editor — the load error names what it objected to.

Reloading the player window does not do this. A reload reattaches to the engine that is already running. Only a genuine change to the bus, DJ app, or deck layout rebuilds the engine, and only then is there anything to put back.


Messages without a code

These are confirmations and progress notes. They need no action; they are listed so that everything the status line can say is accounted for here.

MessageWhat it means
Tempo ramp disarmed: tempo heldYou disarmed the tempo ramp. The deck keeps whatever tempo it has reached: disarming stops the ramp, it does not undo it.
Running RouteFX_A…The named action is running. The name is the action's shortId.
Controls restore sent (12)The transition finished and the outgoing deck's controls were put back where they were before it started, confirmed by telemetry. The count is how many controls moved.
Restored to pre-run stateYou pressed RESTORE after aborting a transition, and everything the run had changed is back where it was before it started: the controls Fusor Studio was driving, the FX routing it had set up, and anything the fusor's post-run actions put back. Roles did not swap — the transition did not happen.
Pre-run setup unwoundA transition was abandoned before it started — you aborted from the pre-run phase, both decks stopped during it, or a pre-run action failed — and Fusor Studio undid the setup that had already been applied. Nothing was mixed and nothing was audible, so it does this by itself rather than asking. After a run has started, it asks instead: the Abort button becomes RESTORE.
Controller reconnected: LPD8 mk2The controller's MIDI port came back and Fusor Studio re-opened it. Your bindings work again, with nothing to re-do.
Controller profile saved on closeYou had unsaved controller bindings open in Settings when a transition started. Settings closes itself while a transition runs, and rather than lose the edit it was written to disk on the way out. The profile was not activated, so the bindings your controller is using right now did not change mid-transition.
File renamed to matchA Fusor's file name follows the Fusor's name, so saving renamed the file to match. You see this most often after renaming a .fusor outside Fusor Studio, in Explorer or Finder: the name inside the file is the one that counts, so the next save puts the file name back. Nothing was lost. The Fusor keeps its place in every collection, because a Fusor is identified by what is inside it and not by where it sits. To change the name for good, change it in Fusor Studio and the file follows.

Reserved codes

NET1, SES1, NET2, NET3, NET4, NET5, ACT5 and ACT6 are reserved and not in use. Fusor Studio does not currently emit them, so you will not see them on the status line. They are listed here only so the numbering has no gaps and no code is ever reused for a different meaning.

NET1, NET2, NET3, NET4 and NET5 belong to automatic telemetry-loss handling: Fusor Studio detecting that the DJ app has stopped answering mid-transition and halting the automation itself. That detection is switched off in this release, because the test it relied on could not tell a quiet DJ app from a disconnected one and it stopped healthy transitions. Fusor Studio stays out of the way instead and leaves the call to you.

What that means in practice: if the DJ app stops responding mid-transition, Fusor Studio keeps running the automation and will not stop by itself. The telemetry light in the player goes amber when Fusor Studio is running a transition and hearing nothing back. That is your signal. Take the transition over on the crossfader, or abort it. See Troubleshooting.

SES1, ACT5 and ACT6 are reserved from behaviour Fusor Studio no longer has. What raised them was changed, so there is nothing left to report and nothing for you to do.