Status Messages

The status line at the bottom of the player window 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 have a code, and the code is what brings you here.

A message longer than the line is cut short with an ellipsis. Rest the pointer on it to read the whole thing. The tooltip shows the full text, including any prefix. Several entries below suggest checking main.log for an untruncated reason; hovering is the quicker route to the same words.

Reading a status message

A warning or an error is prefixed with its code:

CAP5-Uncaptured: sync in Settings
└──┘
 code

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

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

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–CAP9

Control State Capture reads the current position of every control in the DJ app and stores it as a baseline. The Fusor player needs it to know where a transition starts from, and to put the controls back afterwards. It runs when you press Capture State on the player, and can be re-run with Connect and sync (Resync when the light is green) in Settings → Connection.

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 Fusor 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. The Fusor player will not arm a transition without one.

What to do. Choose your DJ app in Settings → Connection, then press Connect and sync there to run a capture.

Fusor Studio does not enter Blind Mode here, as it does after a failed capture. Arming stays blocked until you choose a DJ app.

CAP3: Capture failed: see Settings

CAP3-Capture failed: see Settings

What it means. Capture ran and did not complete, so Fusor Studio has no baseline of the DJ app's control positions. It is running in Blind Mode instead: transitions still run, on a default baseline, without trusting what the DJ app sends back. Fusor Studio leaves Blind Mode by itself, and captures again, as soon as it receives MIDI from the DJ app.

What to do. Usually nothing: touch a control in the DJ app and Fusor Studio receives its MIDI message. To try again yourself, press Connect and sync in Settings → Connection, or turn Blind Mode off in Settings → Connection. If it keeps failing, the MIDI return path is the usual cause (see Troubleshooting).

CAP4: Capture skipped: sync in Settings

CAP4-Capture skipped: sync in Settings

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 of the DJ app's control positions. The Fusor player will not arm or start a transition without one, because it could not put the controls back afterwards.

What to do. Control State Capture was declined. Choose a DJ app in Settings → Connection, then press Connect and sync (Resync if green).

CAP5: Uncaptured: sync in Settings

CAP5-Uncaptured: sync in Settings

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 of the DJ app's control positions. The Fusor player will not arm or start a transition without one, because it could not put the controls back afterwards.

What to do. Control State Capture hasn't run. Choose a DJ app in Settings → Connection, then press Connect and sync (Resync if green).

CAP6: Blind Mode: no MIDI from {app}

CAP6-Blind Mode: no MIDI from Traktor

What it means. Fusor Studio asked the DJ app for its control positions and received no MIDI back at all, so it is running in Blind Mode: transitions still run, on a default baseline, without trusting what the DJ app sends back. Fusor Studio keeps listening, and leaves Blind Mode by itself, capturing again, the first time it receives MIDI from the DJ app.

What to do. If the DJ app was not open yet, open it and touch any control: Fusor Studio receives its MIDI message and reconnects. If it is open and no MIDI arrives, the MIDI bus is usually 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. Once the return path works, press Connect and sync in Settings → Connection.

If Blind Mode switched Run Mode from Manual to Auto, leaving it switches back to Manual.

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. It is running in Blind Mode instead, and leaves it by itself, capturing again, when it receives MIDI from the DJ app.

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 press Connect and sync in Settings → Connection to run the capture again.

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 (Settings → Connection) to capture the app's real control positions. Fusor Studio runs a capture automatically when you do.

CAP9: MIDI from {app}: Blind Mode off

CAP9-MIDI from Traktor: Blind Mode off

What it means. Fusor Studio was running in Blind Mode because a capture had failed, and it has now received MIDI from the DJ app. It leaves Blind Mode and runs a capture straight away. If a transition was armed or running when that MIDI arrived, this waits until the transition ends.

What to do. Nothing. If the capture that follows fails too, Fusor Studio goes back into Blind Mode and stops listening; press Connect and sync in Settings → Connection once the DJ app is set up.

If Blind Mode switched Run Mode from Manual to Auto, leaving it switches back to Manual.

Start and Play: GATE2–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.

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 it has to be playing first. 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 it has to be playing first. 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 Fusor 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, which does work during pre-run and 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–MODE9

The Run Mode switch chooses what drives the progress meter: time (Auto), the crossfader (Manual), or time up to the mix point and the crossfader after it (Mixed).

MODE1: Blind Mode: Auto Run Mode only

MODE1-Blind Mode: Auto Run Mode only

Disables the Run Mode switch while it applies. Hovering shows the same explanation as below.

What it means. Manual or Mixed Run Mode was selected in Blind Mode. Both follow the crossfader, which the Fusor player tracks through telemetry, and Blind Mode ignores telemetry.

What to do. Manual and Mixed Run Modes follow the crossfader through telemetry. Blind Mode ignores telemetry, so only Auto Run Mode can run.

Blind Mode is off at every launch. It is on only if you turned it on in this session, or if Fusor Studio received no MIDI from your DJ app and entered it by itself.

MODE2: Mode locked: transition active

MODE2-Mode locked: transition active

Disables the Run Mode switch while it applies. Hovering shows the same explanation as below.

What it means. The Run Mode switch was pressed during a running transition, including while its pre-run is still being prepared.

What to do. The mode can't change here mid-run. Before the mix point you can hold Auto or Mixed to switch; otherwise abort or finish first.

To take a running Auto or Mixed Run Mode transition over by hand before it stops, press and hold Manual on the switch for about half a second, the same hold Abort uses, once the run is under way. To switch a running Auto Run Mode transition to Mixed, or a Mixed one back to Auto, before the mix point, press and hold that position the same way. A quick press does nothing while the run is under way, and no press changes the mode during pre-run. 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 applies to the bus it was turned on for. On a new bus, Fusor Studio reads telemetry again.

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 in Settings → Connection at any time, except during a run.

MODE5: Lite: Auto Run Mode only

MODE5-Lite: Auto Run Mode only

Disables the Run Mode switch while it applies. Hovering shows the same explanation as below.

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

What to do. Lite runs transitions on the clock so you can see how they work. Mixed and Manual Run Modes need a license.

MODE7: Mixed unavailable: set to Auto

MODE7-Mixed unavailable: set to Auto

What it means. A Fusor was loaded while the run mode switch was on Mixed, and that Fusor's mix point is Start, End without an effect tail, or none. A Mixed run stops at the mix point, so it cannot run this Fusor, and the switch moved to Auto.

What to do. Nothing is required; the transition will run on the clock to the end. To run Mixed, load a Fusor whose mix point is Middle, or End with an effect tail, and press Mixed again: the switch does not move back by itself.

The Run Mode Fusor Studio opens on next time is unchanged: only pressing the switch outside a run changes it.

MODE8: Mixed: no mix point to stop at

MODE8-Mixed: no mix point to stop at

Disables the Run Mode switch while it applies. Hovering shows the same explanation as below.

What it means. Mixed was pressed, on screen or with the controller's Mode button, and the loaded Fusor's mix point is Start, End without an effect tail, or none. A Mixed run stops at the mix point, so there is nowhere for it to stop.

What to do. A Mixed run stops at the mix point and hands the rest to your crossfader. This Fusor has no point to stop at.

The switch shows Mixed dimmed while it cannot run, and the controller's Mode button skips it.

MODE9: Mixed: already past the mix point

MODE9-Mixed: already past the mix point

Disables the Run Mode switch while it applies. Hovering shows the same explanation as below.

What it means. Mixed was pressed during an Auto run after the run had already reached its mix point, so there is no point left for a Mixed run to stop at. Also shown when Mixed was held during an Auto run and the run reached the mix point before the hold finished.

What to do. A Mixed run stops at the mix point, and this run is already past it.

To take the rest of the transition by hand now, press and hold Manual on the switch for about half a second.

Start-with-Incoming: SWI1–SWI3

Start-with-Incoming makes the incoming deck the start trigger: instead of pressing Play, you start the deck in the DJ app and the transition begins when telemetry reports 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 decides how a transition begins, so it can't change 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 the incoming deck's play state, which the Fusor player reads from telemetry, and Blind Mode ignores telemetry.

What to do. Start-with-Incoming waits to see 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 there is no start to wait for. Press Play to start now, or stop the incoming deck first.

Tempo Ramp: TR1–TR11

The tempo ramp syncs the incoming deck to the outgoing deck's tempo as the transition starts, then moves the outgoing deck's tempo over the transition so that both decks end at the incoming track's own tempo. It is app-specific and needs telemetry to confirm each step of its setup took effect.

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. Moving the incoming deck's tempo mid-transition would be audible.

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, and Blind Mode ignores telemetry.

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 would be audible.

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, from where the faders are right now, so the Tempo Ramp toggle stays enabled and refuses the press instead of graying itself out.

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. The designated DJ app has no tempo ramp routine, so the ramp can't arm. Check the DJ app in Settings → Connection, or run without the 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, keep the outgoing deck playing until the run reaches 100%: stopping and restarting it mid-run runs the ramp's setup again, late.

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 the Fusor player.

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 deck's tempo fader has run out of travel at the tempo range it is now set to. Two things cause it. After a transition, the tempo ramp puts the deck's tempo range back the way it found it, and at the tempo the deck is now playing that range leaves the fader pinned at the end of its travel: the tempo is correct, and the fader has no room left to move in that direction. During a transition, you changed that deck's tempo range in the DJ app while the ramp was running, and the new range is too narrow to hold the tempo the ramp was heading for. The ramp keeps running, but it stops short of the tempo the fusor asked for.

What to do. Widen the deck's tempo range in the DJ app. That frees the fader without changing the tempo. If the message appeared after a transition and you would rather it did not happen again, set Tempo range restore to Keep usable in Settings → General; the Fusor player then leaves the range wide enough to use instead of restoring it exactly. If it appeared during a transition, that setting does not apply, because the range you picked mid-run was too narrow for the ramp, so widen it and run the transition again.

TR9: Incoming not following: tempo held

TR9-Incoming not following: tempo held

What it means. The tempo ramp started moving the outgoing deck's tempo, and at that moment the incoming deck's tempo fader was no longer where the ramp had left it. The incoming deck is not following the outgoing deck. The ramp runs anyway. The outgoing deck's tempo moves as the fusor asks, but the incoming deck's tempo stays where it is, so the two tracks will not be tempo-matched when the mix begins.

What to do. Look at the two decks' tempos in the DJ app. If they have drifted apart, match the incoming deck by hand before you bring it in, or abort the transition, set the decks up again, and start it once more.

main.log records both tempo fader positions and how far apart they are (see Logging).

TR10: Tempo corrected {n}%: audible

TR10-Tempo corrected 2.4%: audible

What it means. The tempo ramp finished, and the Fusor player then made a small correction: it nudged the outgoing deck's tempo so the incoming deck's tempo fader ended up back at its center position, which is where it needs to be for the two decks to stay matched after the mix. That nudge moved the outgoing deck's tempo by more than one percent, which is enough to hear. The decks are matched. The message tells you where the sound came from, so you do not go looking for a fault.

What to do. Nothing to fix. If you hear it often and would rather not, the usual cause is starting the transition with the two tracks' tempos further apart, which means a larger tempo change during the ramp and a bigger correction at the end. Getting the incoming deck closer before the mix begins makes the correction smaller.

main.log records the exact fader positions, the deck's tempo range and the size of the move (see Logging).

TR11: Tempo correction stopped short

TR11-Tempo correction stopped short

What it means. The same end-of-ramp correction as TR10, but it did not finish. The Fusor player makes a limited number of attempts to bring the incoming deck's tempo fader back to center, and this time it used them all up and stopped with the fader still off center. The two decks are close but not exactly matched, and the incoming deck's tempo fader is sitting away from the middle, so it has less room to move in one direction than the other.

What to do. Check the incoming deck's tempo fader in the DJ app before you bring it in, and center it by hand if you need the full range of travel. If this happens every time, the deck is most likely not following the tempo changes the Fusor player is sending. Check the deck's sync setting in the DJ app.

main.log records how far off center the fader was left and how many attempts were made (see Logging).

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 the Fusor player logged the failure and continued. 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, and in Mixed Run Mode, which runs on the clock up to its stop, the Fusor player 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 the player 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 the Fusor player 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 Fusor 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 started from a pad, on screen or on your controller, or the FX routing put back after a run, stopped part-way: a step failed or could not be executed, a Wait Until timed out, a Restore had nothing captured to put back, the engine changed state under it, or another action was still running. The reason is quoted in the message; the full text is in the log. A pre-run or post-run action that fails does not show this: its own message (ACT1, ACT2 or ACT4) reports it.

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 Fusor 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 Fusor player is back to Armed. This is the same ceiling as ACT8, applied before the queue starts rather than part-way through it, so the Fusor player refuses at once, without running the queue first.

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, and 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 timed part of the run (the whole transition in Auto Run Mode, the part up to the mix point in Mixed Run Mode), so the transition did not start and none of them ran. The Fusor 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 timed part of your run. 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 (in Mixed, a later mix point also gives it more time). The Fusor player 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 starts once the queue is done.

Controls: CTL1–CTL9

These concern individual controls rather than the transition as a whole. Where CTL1, CTL2 and CTL6 name a control, the Fusor player stops sending to it for the rest of the transition, and it stays where you put it. The rest of the transition runs normally.

CTL3, CTL7 and CTL8 report the opposite: the Fusor player did send controls somewhere, and could not confirm they arrived. CTL9 reports a control the player kept modulating.

CTL1: Incoming {addr} mismatch

CTL1-Incoming eq.high mismatch

What it means. One of the fusor's parameters on the incoming deck is too far from where the fusor expects to start. Modulating it would jump the control audibly, so the Fusor player 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 of the fusor's parameters on the incoming deck are too far from where the fusor expects to start. The Fusor player 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 the Fusor player sent the outgoing deck's controls back to where they were before it started, but no telemetry came back to confirm they arrived. 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).

CTL6: Manual takeover: {addr}

CTL6-Manual takeover: eq.mid

What it means. You moved a control the Fusor player was modulating. The player released that one control to you for the rest of the transition and stopped sending to it. The rest of the transition keeps running.

What to do. Nothing. To have the fusor modulate the control again, abort and re-arm. Taking a control by hand does not change what happens to it when the run ends: on the outgoing deck, the End of run setting on that domain still applies, exactly as it would have. Restore puts the control back to where it was when the transition started, Leave sends nothing and it stays where your hand left it, and Home sends it to its home position.

This is per-control. Taking the whole transition over is different: press and hold Manual on the Run Mode switch instead. 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 the Fusor player 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 arrived. 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).

CTL8: Sent home ({n}): unconfirmed

CTL8-Sent home (4): unconfirmed

What it means. The transition finished and the Fusor player sent one or more domains to their home positions, but no telemetry came back to confirm they arrived. 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 outgoing deck in the DJ app and move anything that did not follow by hand. If it happens every time and you are not in Blind Mode, the MIDI return path is the cause (see Troubleshooting).

Going home is not the same as being put back. A domain set to Home ends at the positions the control itself defines as neutral, whatever the deck looked like before the transition.

CTL9: Knob takeover off: {addr}

CTL9-Knob takeover off: eq.mid

What it means. You moved a control the Fusor player was modulating while the transition was running, and the Allow knob takeover during a run setting is off, so the player kept modulating it. Your movement was overwritten by its next send. This message appears the first time it happens to each control in a transition; after that it is only logged.

What to do. In an Auto run, or a Mixed run before its stop, pause the transition first: while it is paused, moving a control always releases it to you. A Manual run, and a Mixed run after its stop, has no pause, so the control stays modulated until the run ends or is aborted. Or turn Allow knob takeover during a run back on in Settings.

Pads: PAD1–PAD7

The eight pads trigger actions from the active pack. Every PAD message means nothing was sent. An action that starts and then fails is ACT7, whichever pad fired it.

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 grayed, 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 is empty. 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 or clicked and the action bound to it failed validation, so none of its steps ran. A step that names a position the control does not have, or a control Fusor Studio can only read, fails validation.

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 gray the pad out in advance.

PAD5: {pad}: {reason}

PAD5-Pad 7: unreadable action file

What it means. A pad could not run its action because the action file could not be read, or is outside the actions folder of your library, or the active pack's file could not be read, so nothing was sent. This applies to a pad pressed on your controller or clicked on screen. An action that fails validation is PAD4, and an action that stops part-way is ACT7, from either pad.

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

PAD6: {pad}: couldn't read settings

PAD6-Pad 4: couldn't read settings

What it means. A pad was pressed or clicked and Fusor Studio could not read its own settings or find your library folder, so it could not tell which pack is active or where the action file is. Nothing was sent.

What to do. Check main.log for the full error (see Logging). Restart Fusor Studio; if it happens again, check the library folder in Settings → General.

PAD7: {pad}: not during a transition

PAD7-Pad 5: not during a transition

What it means. A pad was pressed or clicked while a transition was under way. Pad actions run only between transitions, so nothing was sent.

What to do. Press the pad again once the transition has finished or been aborted.

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 cover both controller profiles chosen in Settings → Connection, the DJ controller and the Fusor controller, and the message names which one.

HW1: {job} unplugged: {port}

HW1-DJ controller unplugged: 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 "DJ controller reconnected" or "Fusor 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 → Mapping, on the tab the message names (DJ controller or Fusor controller), from the gear beside the profile name.

HW2: {job} missing: {port}

HW2-DJ controller missing: LPD8 mk2

What it means. A controller profile is chosen, 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. Fusor Studio can't find this controller's MIDI input. Plug the controller in and it connects on its own. If you're not using it, choose another profile in Settings → Connection: None for the DJ controller, or None or Same as my DJ controller for the Fusor controller.

Both Decks Stopped: RUN1–RUN3

A transition needs at least one deck playing. These messages fire when the Fusor player 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, and was still setting up, so there was nothing to hold and the Fusor player 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. The Fusor player 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, the Fusor player undoes that for you, and 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 the Fusor player paused it. The run is not over. The meter holds where it had reached, the player stays armed, and every control the transition was modulating stays exactly where the fusor last set 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. The Fusor player keeps hold of the controls it was modulating 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–SES9

These fire as a fusor loads, and they report something the Fusor player did to it, or to the state around it, on the way in. Loading is not always something you asked for directly: saving an edit in the library makes the player read the fusor again, and that is a load like any other.

A fusor can modulate parameters your DJ app does not have. The Fusor player 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. The player 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.

Loading also lets go of an arm. Arming holds one fusor ready to run, so loading a different one, or reloading the same one after an edit, leaves nothing to hold ready.

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

SES2-2 domains off: not in Traktor

What it means. The fusor you loaded modulates parameters your DJ app does not have, so the Fusor player 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.

SES3: {n} domains off: nothing specific

SES3-3 domains off: nothing specific

What it means. The same as SES2, and every domain still on is one that no DJ application in Fusor Studio's compatibility records lacks, so none of the fusor's application-specific domains is left running. Those records are still empty for most applications, so a domain that is still on is not known to work everywhere.

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 modulates a parameter your DJ app does not have, so the Fusor player 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.

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 every domain still on is one that no DJ application in Fusor Studio's compatibility records lacks, so none of the fusor's application-specific domains is left running. Those records are still empty for most applications, so a domain that is still on is not known to work everywhere.

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 parameters the fusor modulates. Nothing is loaded now.

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

Recovering the player window after a display crash does not do this. Recovery 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.

SES8: Disarmed: {name} loaded

SES8-Disarmed: EQ Swap loaded

What it means. A fusor was loaded while another one was armed, so the arm was let go. Arming holds one fusor ready to run; loading replaces the fusor that is held, so there is no longer anything to hold ready. Nothing was sent to your DJ app, and the fusor named in the message is the one that is loaded now.

What to do. Press Arm again once the fusor you want is loaded.

You do not have to have pressed anything for this to happen. Editing the loaded fusor in the library saves it, and saving it makes the Fusor player read it again, which is a load, and a load lets the arm go. If you are about to mix, finish the edit first and arm after.

SES9: This run only: not saved to file

SES9-This run only: not saved to file

What it means. You changed something in Session View (a domain or action switched on or off, an FX unit, an FX slot order, what a domain does at the end of the run). The change is in effect for this run, but Fusor Studio could not write it into the fusor file, so it will not be there the next time you load this fusor.

What to do. Check main.log for why the file could not be written (see Logging), for example a read-only file or one held by a sync app. Once it can be written, make the change again; that change is saved.

Startup and windows: APP1–APP4

Only one copy of Fusor Studio runs at a time. A settings file with a value of the wrong type is reported at startup. A window that crashes is closed for you, except the player window, which is recovered.

APP1: Launch blocked: already running

APP1-Launch blocked: already running

What it means. Fusor Studio was started while a copy of it was already running. The new copy closed before opening a window, and the copy already running was brought to the front. Nothing in it changed: a transition in progress keeps running.

What to do. Nothing is required. To restart Fusor Studio, quit it first, then start it again.

APP2: Settings file: bad value ignored

APP2-Settings file: bad value ignored

What it means. Fusor Studio started with a settings file that holds a value of the wrong type, for example a number typed inside quotes ("16" in place of 16). Each such setting is at its default. Every other setting in the file was read as usual.

What to do. Check main.log (see Logging): it names each ignored setting and the value it held. To use your own value again, set it in Settings. A setting with no control in Settings is corrected in the settings file, fusor-settings.json, in the folder that holds the logs folder.

APP3: Closed {window} (crashed)

APP3-Closed Library (crashed)

What it means. One of Fusor Studio's windows crashed: the Library, Settings, an editor, the Step Sets window, a Set List Builder or a question box. A crashed window goes blank and cannot be closed, moved or minimized, so Fusor Studio closed it. The message names the window. Anything not saved in that window was lost when it crashed. The player window is not affected: a transition in progress keeps running.

What to do. Open the window again the way you opened it before, and redo any change you had not saved. If the same window keeps crashing, check main.log (see Logging) for a [render-process-gone] line, which records why.

APP4: Crash recovered

APP4-Crash recovered

What it means. The Fusor player's display crashed and has been brought back, either by Fusor Studio on its own after the player went blank, or because you pressed Recover on the player's Display crashed panel. The engine behind the display was not touched: the loaded fusor is still loaded, and a transition that was running kept running the whole time. The player shows the current state again as it comes back, and the Display crashed panel says whether a transition is still running.

What to do. Nothing is required. If the Fusor player keeps crashing, Fusor Studio stops bringing it back after the third crash in a minute and leaves it blank; a transition that was running still runs to its end. Quit and restart Fusor Studio, and check main.log (see Logging) for the [render-process-gone] lines, which record why.

License: LIC1

Fusor Studio Lite, the version that runs without a license, plays fusors and keeps every change you make in Session View. Creating and changing fusors needs a license.

LIC1: Changing fusors needs a license

LIC1-Changing fusors needs a license

What it means. Fusor Studio Lite does not create, duplicate or change fusors, and a change of that kind reached the save: an edit in the library, a new or duplicated fusor, a domain import, or a step set saved or deleted. The change was not saved. Lite does not offer these in the first place, so this shows only when one gets through. It is shown once per fusor while the library is open.

What to do. Nothing is needed to keep playing fusors. To create or change them, activate a license in Settings → License and restart Fusor Studio. Your Notes and the changes you make in Session View are saved in Lite as usual.

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.

Reserved codes

NET1, SES1, NET2, NET3, NET4, NET5, ACT5 and ACT6 are reserved and not in use. Fusor Studio does not 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: the Fusor player detecting that telemetry from the DJ app has stopped mid-transition and halting the transition 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.

What that means in practice: if the DJ app stops responding mid-transition, the Fusor player keeps running the transition and will not stop by itself. The telemetry light in the player goes amber when the player is running a transition and receiving no MIDI back, which means the connection from the DJ app may have been lost. Press Abort and hold to stop the transition, then mix manually from where the controls stand. Taking the transition over by hand does not fix this either: Manual Run Mode also takes its progress from the crossfader position the DJ app reports back, the same feed that has gone quiet. See Troubleshooting.

SES1, ACT5 and ACT6 are reserved, with nothing to report and nothing for you to do.