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.

MIDI issues

No MIDI ports appear in Fusor Studio settings

• Probable cause: Your MIDI bus isn't running, or no endpoints exist.
• Fix: Confirm loopMIDI is running with a single port created, or that FusorBus is active in the WMS MIDI Settings app. Restart Fusor Studio after creating the port.

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 Fusor Studio automates. See Traktor Pro Setup for instructions.

Manual takeover doesn't trigger

• Potential cause: Fusor Studio is not receiving crossfader telemetry from the DJ app.
• Fix: Verify that:
  • The DJ app has an Output mapping for the crossfader, sending to the same Fusor bus on channels 9–16.
  • Fusor Studio's Fusor MIDI Bus (Settings → Connection) is set to that bus.
  • The Fusor mapping file for your DJ app is imported (it configures the telemetry outputs).

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's channel split (out on 1–8, in on 9–16) prevents echo on its own as long as the DJ app's mapping respects that split. The Fusor TSI is set up correctly.

The DJ app stopped responding during a transition

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

Fusor Studio will not stop the transition for you. It keeps sending, and it will run to the end regardless. There is no reliable way to tell a disconnected DJ app from a quiet one, because a DJ app only reports a control when that control actually changes. Halting on suspicion would mean cutting healthy transitions short mid-set, so Fusor Studio shows you what it sees and keeps going until you say otherwise.

What to do while it's happening:

• Take it over. Grab the crossfader and finish the blend by hand. Fusor Studio hands you control the moment you move it. This is the safe move mid-set.
• Or abort. Press Abort to drop the automation and mix manually from where you are.

If the transition reaches the end and just sits 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. On a dead feed it can never arrive, so the player waits indefinitely, showing Completed. Press END to finalize it by hand, then fix the feed below.

What to do afterwards:

1. Restart the DJ app. A dead feed usually means its 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. Re-run Capture Control State from 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, not when Fusor Studio stops asking. Touching any control over there is the quickest way to confirm the feed is back. For the other colours and what each one claims, 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. Engine and renderer logs at %APPDATA%\fusor-studio\logs\ 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's compact fallback says Display crashed; every other window says Render error. Either way the window stays movable and closable: it shows a title bar with a close button, so you never need Task Manager.

• In Settings, the Library, or an editor: close the window and reopen it. Nothing else is affected.
• In the player: you get two buttons, Reload and Quit Fusor. Which one is safe depends on whether a transition is running.

If a transition is playing, do not press Reload. The display and the engine are separate: when the display crashes, the transition keeps running normally — your EQs, crossfader and effects keep moving, and it will finish and restore your controls on its own. Reload restarts the engine, which stops it. Let the transition finish first, then reload to get the display back.

Outside the player, the window shows the error message and its stack trace inline, so you can read it without opening a log. The player's fallback is too small for that and writes the details to the log only. See Logging.

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 holder, 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.

"Controller not connected" appears when Fusor Studio starts

• Probable cause: A controller profile is still active 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.
• Fix: If you meant to use the controller, plug it in. Fusor Studio keeps watching for the port and attaches on its own, showing "Controller reconnected: <port name>". If you're not using it this session, deactivate the profile in the Input Mapping settings tab so the notice 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 there.
• Note: The notice 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 goes dead 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 "HW1-Controller disconnected: <port name>" warning and switches the profile to Reconnecting.
• Fix: Plug the controller back in. Fusor Studio reopens the port on its own, re-applies the profile's bindings, and shows "Controller 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 Input Mapping settings tab. If the controller is plugged in, bindings do nothing, and Fusor Studio isn't showing HW1, the port itself may be wedged rather than gone, so unplug and replug it. See Hardware Controller.

MIDI Learn picks the wrong control

• Potential cause: A neighbouring control (an accidentally-bumped pad, a jittery modifier wheel) sent more messages than the control you actually 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 holder 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.