Troubleshooting

If you're looking at a status-line code (like CAP5 or CTL1), skip straight to Status Messages, which covers every code directly. This page is for problems that don't come with a code attached, and for crashed windows.

MIDI issues

No MIDI ports appear in Fusor Studio settings

• Probable cause: Your MIDI bus isn't running, or no endpoints exist.
• Fix: On Windows, confirm loopMIDI is running with a port named Fusor Studio, or that your bus is active in the WMS MIDI Settings app. Restart Fusor Studio after creating the port. On the Mac, Fusor Studio uses its own connection, Fusor Studio, and needs no other port. If your DJ app does not list Fusor Studio, restart Fusor Studio.

Fusor Studio is running but DJ app controls don't move

• Potential cause: Bus mismatch between Fusor Studio and the DJ app.
• Fix: Verify that:
  • Fusor Studio's Fusor MIDI Bus (Settings → Connection) is the same bus the DJ app is bound to as its In-Port.
  • In the DJ app's MIDI device settings, the In-Port is bound to the specific Fusor bus (not "All Ports").
  • The DJ app's MIDI mapping is loaded and active.

Crossfader jumps when moved during a transition

• Probable cause: Soft takeover is not enabled on the crossfader mapping in the DJ app.
• Fix: Enable soft takeover on all controls that the Fusor player modulates. See Traktor Pro Setup for instructions.

Manual takeover doesn't trigger

• Potential cause: Manual on the Run Mode switch wasn't held long enough, or Blind Mode is on.
• Fix: Press and hold Manual on the Run Mode switch (on screen, or the mapped Run Mode MIDI button) for about 0.4 seconds; a quick press does nothing while a run is under way, and letting go early cancels it. Manual takeover is unavailable in Blind Mode. See Manual takeover.

Transition won't complete (stuck at 100%)

• Probable cause: The outgoing deck is still playing. Completion requires both progress at 100% AND the outgoing deck stopped.
• Fix: Stop the outgoing deck manually, let it reach the end of the track, or press the End button on the progress strip to commit the transition immediately. Verify that deck play state telemetry is configured (the DJ app must send deck playing/stopped state to Fusor Studio).

MIDI feedback loop (controls oscillate)

• Potential cause: "All Ports" is selected in the DJ app, or the DJ app is echoing MIDI received on channels 1–8 back out on those same channels.
• Fix: In the DJ app, bind In-Port and Out-Port to the specific Fusor bus (not "All Ports"). Fusor Studio's channel split (out on 1–8, in on 9–16) prevents echo on its own as long as the DJ app's mapping follows that split. The Fusor TSI already does.

The DJ app stopped responding during a transition

What you'll see: the telemetry light in the player window turns amber while a transition is running, and the DJ app's controls stop moving even though the Fusor player's progress bar keeps advancing. The music does not change the way you expect.

The Fusor player does not stop the transition: it keeps sending MIDI and runs to the end. A DJ app sends a control's value only when that control changes, so the player cannot tell a disconnected DJ app from one that has nothing to report.

What to do while it's happening:

• Abort. Press Abort and hold. The transition stops and the controls stay where they are. Mix manually from there.
• Taking the transition over by hand does not fix this. Press and hold Manual on the Run Mode switch to convert the run to Manual, but Manual Run Mode also reads progress from the crossfader telemetry, which is what has stopped arriving. Progress will not follow your hand until telemetry returns.

The Fusor player may still be reaching the DJ app. Only telemetry is missing, so the fusor can still be modulating controls in the DJ app. The DJ app's own screen shows whether it is.

If the transition reaches the end and stays there: this is the same fault. A transition finishes by waiting for the outgoing deck to stop, and that signal comes from the DJ app. Without telemetry it never arrives, so the Fusor player waits indefinitely, showing Completed. Press END to finalize it by hand, then restore telemetry as below.

What to do afterwards:

1. Restart the DJ app. Missing telemetry usually means the DJ app's MIDI output has latched; Fusor Studio cannot reopen a port the app has stopped sending on. Restarting the DJ app clears it. (Restarting Fusor Studio alone does not.)
2. Press Connect and sync (Resync when the light is green) on Settings → Connection once it's back, so Fusor Studio has a fresh baseline.
3. If it keeps happening, check main.log (Logging) and see MIDI Mapping for the return-path setup.

Expect the light to stay amber after the transition ends. It goes green when the DJ app sends something. Moving any control in the DJ app is the quickest way to confirm telemetry is back. For the other colors and what each one means, see the telemetry indicator.

djay Pro doesn't return telemetry

• Probable cause: djay Pro doesn't broadcast deck state over MIDI.
• Fix: Turn on Blind Mode. See the Blind Mode chapter.

Application issues

Fusor Studio window is blank on launch

• Potential cause: Renderer process failed to load. This can happen if a previous crash left stale state.
• Fix: Close Fusor Studio completely and relaunch. main.log in %APPDATA%\fusor-studio\logs\ (Windows) or ~/Library/Application Support/fusor-studio/logs/ (Mac) may show the underlying error. See Logging.

A window shows "Render error" or "Display crashed"

Any Fusor Studio window can hit a display error. The player window's compact fallback says Display crashed; every other window says Render error. Either way the window stays movable, and you never need Task Manager: every other window shows a title bar with a close button, and the player shows two buttons.

• In Settings, the Library, or an editor: close the window and reopen it. Nothing else is affected.
• In the player: press Recover to bring the player back. Quit Fusor Studio closes the app.

The display and the engine are separate. When the display crashes, a transition keeps running normally: your EQs, crossfader and effects keep moving, and it finishes on its own. While one is running, the player window's panel says Transition still running. Fusor Studio recovers from a display crash by itself too: a player that goes blank comes back on its own.

Every window writes the error details to the log. Outside the player window, the window also shows the error message and its stack trace inline. See Logging.

A window closed itself, or the player went blank and came back

A window can also crash outright and go blank, with no error shown. Fusor Studio then closes it, or recovers it if it is the player window, and the player window's status line shows a message.

• Settings, the Library, an editor or another window is closed, and the message names it, for example APP3-Closed Library (crashed). Anything not saved in that window is lost. Open it again the way you opened it before. See APP3.
• The player is recovered, with APP4-Crash recovered. A transition in progress keeps running and the loaded fusor stays loaded; while one is still running, the Display crashed panel says so. See APP4.

Fusor Studio recovers the player window up to three times in a minute. If it crashes again inside that minute, the player stays blank and the engine keeps running. Close Fusor Studio from its taskbar button, start it again, and check main.log for the [render-process-gone] lines, which record why. See Logging.

A save or import fails with "Details are in the log."

• Potential cause: something unexpected stopped the save or import, for example "Save failed. Details are in the log." in the domain or action editor, "<name> not saved. Details are in the log." in the Library, or "Duration override failed. Details are in the log." in Session View. When Fusor Studio refuses for a reason it can name, the line says so instead, for example "Import failed: Open the Library and try again."
• Fix: try again. If it keeps happening, look in main.log for the technical detail, which is written there and not on screen. See Logging.

An FX unit is silent for the whole transition

• Potential cause: no slot is switched on. A fusor owns every slot of a unit it uses, so any slot you do not switch on is switched off when the transition starts, and with all three off the unit passes nothing however the Dry/Wet moves.
• Fix: switch on the slot holding your effect. The domain card says so while you author: "nothing will be heard." See FX Routing → a fusor owns the whole FX unit.

An FX unit plays whatever is loaded in the slot

• Potential cause: the fusor switches a slot on but never names the effect it expects there. Fusor Studio warns about this and still opens and runs the fusor, which plays whatever effect is loaded in that slot. That effect can differ between sessions.
• Fix: load the effect the fusor expects into that slot before you start. A fusor you load names the slot on the Session View card: "Slot 1 of the outgoing FX unit is switched on, but this Fusor does not say which effect it wants — it will play whatever is loaded there." If you are authoring the fusor, the domain card shows the same warning as a chip, "Outgoing: no effect declared", and the fix there is to declare the effect on the slot: double-click the slot's tab in the curve editor and type the effect's name. See FX Routing → Naming the effect on a slot.

An effect I had running stopped when the transition started

• Potential cause: it was in a slot of an FX unit the fusor uses. This is by design: the unit's Dry/Wet is shared by all three slots, so a fusor sweeping it would move your effect anyway, and the fusor switches off the slots it is not modulating.
• Fix: put your own effect in a different FX unit from the one the fusor uses. See FX Routing → a fusor owns the whole FX unit.

An effect is still running after the transition finished

• Potential cause: the fusor's curves ended with the unit's Dry/Wet still open, or a slot still switched on, and End of run left it that way. On the outgoing side that means the domain's End of run is set to Leave, because Home and Restore both close the unit. On the incoming side an open Dry/Wet is never put back by any End of run setting, and a slot Enable is put back only by Restore.
• Fix: bring the curve down before the end, fade the effect out inside the run, or change End of run. Fusor Studio warns you either way. While you author, the FX Unit's domain card shows a chip: "left enabled and wet", "Dry/Wet left open" or "slot left enabled", with the side named. With an Effect tail on the outgoing FX Unit, the tail fades Dry/Wet to dry, so Leave leaves the slot enabled but dry; where the tail is available and off, the chip's tooltip suggests it. On a fusor you have loaded, the same check states what will be left behind on the domain card in Session View. See FX Routing → ending with the unit still open.

Hardware controller issues

Activate fails with "Port in use"

• Probable cause: Your DJ app or another process is holding the controller's MIDI port exclusively. On Windows, WinMM ports are exclusive: only one app can open a given port at a time.
• Fix: Close the application holding the port, or route the controller through a virtual MIDI port (e.g. loopMIDI or a WMS loopback) so both apps can attach. See Hardware Controller.

Activate fails with "Port not found"

• Probable cause: The MIDI port named in the profile isn't currently visible (controller unplugged, USB hub asleep, port renamed by the OS).
• Fix: Replug the controller and wait. Fusor Studio polls every few seconds and reactivates the profile automatically. If the port name has changed, edit the profile's MIDI Input Port and re-save.

"DJ controller missing" or "Fusor controller missing" appears when Fusor Studio starts

• Probable cause: A controller profile is still chosen for the DJ controller or the Fusor controller from a previous session, but the MIDI port it expects isn't there: the controller is unplugged, powered off, or its port has been renamed by the OS. This is the startup counterpart to HW1. HW1 means a controller that was working went away; HW2 means one was expected and never arrived. The panel names the job it's missing, "DJ controller missing: <port>" or "Fusor controller missing: <port>", and you see one panel per missing job if both are.
• Fix: If you meant to use the controller, plug it in. Fusor Studio keeps watching for the port and attaches on its own; the panel closes if the controller connects before you dismiss it, and otherwise the connection is confirmed by "<job> reconnected: <port>". If you're not using it this session, choose None for the DJ controller, or choose None or Same as my DJ controller for the Fusor controller. If you're using a different controller for that job, choose its profile instead. Any of these choices closes that job's notice (Settings → Connection, or the profile dropdown on either Mapping controller tab), so the panel doesn't return at every launch. If the controller is plugged in and the message persists, its port may have reappeared under a different name and has to be reselected on the Mapping page.
• Note: Each panel appears once per launch, after Control State Capture is dealt with, and dismisses with OK. Nothing else is affected, and the on-screen controls all work normally.

Controller stops responding mid-session

• Probable cause: The controller's MIDI port disappeared: the USB cable was pulled, the controller lost power, or a hub dropped it. Fusor Studio shows a "<job> unplugged: <port name>" warning, naming the DJ controller or the Fusor controller, and switches that job to reconnecting.
• Fix: Plug the controller back in. Fusor Studio reopens the port on its own, re-applies the profile's bindings, and shows "<job> reconnected: <port name>". You don't need to reactivate the profile by hand. If the port comes back under a different name, reselect it in the profile bar's gear popover (Settings → Mapping, either controller tab). If the controller is plugged in, bindings do nothing, and Fusor Studio isn't showing HW1, the port may still be listed but not delivering MIDI, so unplug and replug it. See Hardware Controller.

MIDI Learn picks the wrong control

• Potential cause: A neighboring control, such as an accidentally-bumped pad or a jittery modifier wheel, sent more messages than the control you wanted.
• Fix: Click Learn again and move the target control more deliberately. Fusor Studio uses the most-frequent source in the learn buffer, so a few clean reads of the right control dominate the result.

Learn shows a port error

• Probable cause: Learn opens the profile's own connection to its selected MIDI Input Port, independent of whether that profile is activated. The same causes as an Activate failure apply: the port is held by another application, or the controller isn't currently plugged in.
• Fix: See the fixes above for "Port in use" and "Port not found": close the application holding the port, or pick a different port, or plug the controller in and try Learn again.

Known issues

Getting help

If your issue isn't covered here, capture a verbose log (see Logging) and file it against the Fusor Studio repository.