A PS5 controller not detected as MIDI is almost always one of four things: a charge-only cable, Steam holding the controller exclusively, a missing operating system permission, or a host that cached its MIDI port list before the bridge started. This is a triage, ordered cheapest and most likely first. Work down it and stop the moment input arrives — there is no prize for completing the list. Note the scope: this is for a controller that has never worked. If yours connects fine and then vanishes mid-session, that is a different fault with a different cause, covered in the DualSense disconnect guide.
- What you do: identify which layer is failing, then work down seven fixes in order and stop when it works.
- What you need: a known-good USB data cable and a terminal or PowerShell window.
- Time: 2 minutes for the common case, 15 for the full sweep.
- Cost:
$0, unless the answer turns out to be a cable.
Which layer is actually broken?
There are three layers between the controller and your music software, and the fix is completely different depending on which one is failing — so find out before you change anything.
The chain runs: controller → operating system HID stack → bridge app → virtual MIDI port → your DAW. Ask three questions in order.
Does the operating system see the controller? Not the app — the OS. Run the matching command for your platform:
# macOS
ioreg -p IOUSB -l | grep -i DualSense
# Windows (PowerShell)
Get-PnpDevice -Class HIDClass | Where-Object FriendlyName -like "*Wireless Controller*"
# Linux
lsusb | grep -i Sony If nothing comes back, the problem is physical — cable, port, or pairing. Go to Fix 1. The app is not involved yet and no amount of reinstalling it will help.
Does the bridge see the controller? The status chip in the top bar flips from No controller to a coloured chip with the device name roughly 200 ms after the OS enumerates it. If the OS can see the controller but the chip stays red, click the chip — it opens a diagnostics panel that names the process holding the device exclusively, or tells you a permission is missing. That is usually the whole answer, and it points you at Fix 2, 3, or 4.
Does your DAW see the port? If the chip is green and the controller responds inside the app's own MIDI monitor, but your DAW shows no Universal Controller input, the controller is fine and the port is the problem. Skip straight to Fix 7.
Fix 1 — Is it a charge-only cable?
Swap the cable for the one that came in the controller's box, because many USB-C cables carry power but no data lines.
This is the single most common cause and the most frustrating, because the controller lights up. Power is clearly flowing. It looks connected. But without the D+ and D− data lines, the host never enumerates it as an HID device, so the operating system genuinely does not know anything is plugged in — which is exactly what the Fix 0 command above will tell you.
The in-box DualSense cable is always a data cable. Apple's white USB-C charge cable is not, and it is the most common culprit on Macs specifically because it is the cable sitting on the desk. If you are buying one, the listing needs to say "data" or "sync", not just a wattage rating.
Try a different port while you are here. Front-panel USB ports on desktop cases are frequently wired at USB 2.0 speeds with poor shielding; a rear motherboard port is more reliable.
Fix 2 — Is Steam holding the controller?
Quit Steam, or turn off PlayStation Configuration Support in Steam → Settings → Controller, because Steam Input can claim the device exclusively.
This fault has a distinctive signature: the operating system sees the controller, the bridge sees the controller, the status chip may even go green — and absolutely no input arrives. Steam Input has grabbed exclusive access and is swallowing the HID reports before anything else gets them.
Quitting Steam entirely is the fastest test. If that fixes it and you want to keep Steam running day to day, the targeted setting is Steam → Settings → Controller, then turn off PlayStation Configuration Support. On macOS, also check that Apple's own controllerd has not taken over.
On Windows the same logic applies to DS4Windows and similar remapping tools. They work by taking exclusive control of the physical controller and presenting a virtual one — which is exactly the behaviour that starves a MIDI bridge. Close them before testing.
Fix 3 — Has macOS granted Input Monitoring?
Enable Universal Controller MIDI under System Settings → Privacy & Security → Input Monitoring, and if it already looks enabled but still fails, reset the stale permission entry.
macOS requires Input Monitoring for any app reading HID input, and for wireless you also need the Bluetooth permission. The onboarding wizard requests both on first launch, but a denied prompt or an upgrade from an older build can leave you stuck.
The confusing version of this is when the permission looks granted and nothing works anyway. That is almost always macOS's privacy database holding a stale entry for an older build with the same bundle identifier. Clear it:
# Reset the privacy entries for the app, then relaunch it
tccutil reset All com.aidxn.universalcontrollermidi Relaunch the app afterwards and accept the prompts when they reappear. You will need to grant Input Monitoring again from scratch — that is the point.
Fix 4 — Is the Linux udev rule loaded?
Install the udev rule and run sudo udevadm trigger, because without it the controller's device node is readable only by root.
On Linux the symptom is specific and recognisable: the controller is clearly present — lsusb lists it — but the app cannot open it, and running the app with sudo makes it work. That is the tell. It is a permissions problem on the device node, not a detection problem.
# After installing the rule, reload and re-trigger
sudo udevadm control --reload-rules
sudo udevadm trigger
# Then unplug and reconnect the controller
Resist the urge to just keep running the app as root. Beyond the obvious, launching with sudo once can leave config directories owned by root, which then produces a second, unrelated fault where the onboarding wizard re-runs on every launch because it cannot write its own state file.
Fix 5 — Did Windows pair it as a generic HID device?
Remove the device, hold PS for ten seconds to fully power the controller down, wait, then pair again from Bluetooth & devices.
Windows occasionally pairs a DualSense as a generic HID gamepad rather than recognising it properly. The symptom is that it connects and reports input, but the axes are wrong, stuck, or inverted — buttons map to nothing sensible and sticks behave bizarrely. It looks like a bug in the mapping and it is not.
The fix is a clean re-pair, and the order matters. Remove the device from Settings → Bluetooth & devices. Then power the controller fully off by holding PS for about ten seconds, not just letting it idle. Give Windows ten seconds or so to clear its device cache. Then put the controller back into pairing mode with PS + Create, held for a full five seconds until the light bar is actively flashing blue, and pair again.
If it still comes up wrong, test over USB. A controller that behaves correctly wired and incorrectly over Bluetooth confirms the pairing is the problem rather than the controller.
Fix 6 — Is the USB hub starving it?
Plug the controller directly into the computer, not through a hub shared with a webcam or an audio interface.
Hubs cause two distinct failures. The first is detection that comes and goes every few seconds as bandwidth is contended — typically when a webcam or audio interface is on the same hub pushing continuous isochronous traffic. The second is an unpowered hub failing to supply enough current for a controller that is both operating and charging.
Both have the same fix. Take the controller off the hub and give it a direct port, ideally a rear one on a desktop. If the controller needs to live on a hub in your setup, a powered hub with its own supply is the minimum.
Fix 7 — Is the port missing because the DAW cached its MIDI list?
Quit your DAW, confirm the bridge is running, then open the DAW again — most music software enumerates MIDI ports once at launch and never re-scans.
This is the fix for the case where everything is actually fine. The controller is connected, the status chip is green, the app's MIDI monitor shows notes and CCs arriving when you press buttons — and your DAW's MIDI input list has no Universal Controller in it. Nothing is broken. The DAW built its port list before the port existed.
The habit that prevents this permanently: open the bridge before the host, every time. The port needs to exist first. If the port is still absent after a restart, the fault has moved from the controller to the port itself — work through the MIDI port not showing up guide, and read how to create a virtual MIDI port for what the bridge is doing on each operating system.
On macOS there is one extra thing to confirm. The virtual port routes through the IAC Driver, and the IAC Driver can be switched off at the system level. Open Audio MIDI Setup, choose Window → Show MIDI Studio, double-click IAC Driver, and make sure Device is online is ticked. On Windows the bundled teVirtualMIDI driver handles this with no configuration — if port creation failed there, re-run the installer elevated and reboot. On Linux the port is an ALSA sequencer client and needs no setup at all.
Last resort — the hardware reset
Press the pinhole reset button on the back of the controller near the L2 trigger for five seconds, after powering it off and removing the stale pairing from your operating system.
Keep this for when everything above has failed, particularly if the controller has been paired to a phone or another console in between. A DualSense remembers exactly one host, and pairing it elsewhere silently destroys the desktop pairing.
# 1. Hold PS for ~10 s to power the controller off
# 2. Press the pinhole reset on the back near L2 with a paperclip, 5 s
# 3. Remove the stale pairing from the host first:
# macOS: blueutil --unpair AA:BB:CC:DD:EE:FF
# Linux: bluetoothctl remove AA:BB:CC:DD:EE:FF
# 4. Re-enter pairing mode with PS + Create and pair fresh One last sanity check if you are wireless and nothing has worked: try a cable. A controller that works perfectly over USB and never over Bluetooth narrows the problem to the radio path, and the trade-offs there are worth understanding on their own terms — see wired versus Bluetooth for PS5 controller MIDI. For the full setup from scratch, go back to how to use a PS5 controller as a MIDI controller.
If you have not installed the bridge yet and landed here first, start at the downloads page — the free build is enough to confirm whether the controller works before you spend anything.
FAQ
Why is my PS5 controller not detected at all?
In order of likelihood: a charge-only USB cable, Steam Input holding the device exclusively, a missing macOS Input Monitoring permission, or a missing Linux udev rule. Check which layer is failing before you change anything.
How do I check whether my computer sees the DualSense?
Run ioreg -p IOUSB -l piped to grep for DualSense on macOS, Get-PnpDevice -Class HIDClass filtered for Wireless Controller on Windows, or lsusb piped to grep for Sony on Linux. If none of them return the controller, the problem is the cable or the port, not the app.
Does Steam stop a PS5 controller working as a MIDI controller?
Yes. Steam Input can claim the controller exclusively, so the app sees the device but receives no input. Quit Steam, or turn off PlayStation Configuration Support in Steam, Settings, Controller.
Why does my DualSense work but the MIDI port is missing in my DAW?
Because the DAW enumerated its MIDI inputs at launch and the port appeared afterwards. Quit the DAW, confirm the bridge is running, and open the DAW again. On macOS also check the IAC Driver is online in Audio MIDI Setup.
How do I hard reset a DualSense that will not connect?
Power the controller off by holding PS for about ten seconds, then press the pinhole reset button on the back near the L2 trigger with a paperclip for five seconds. Remove the stale pairing from your operating system before reconnecting.
Is a controller that is never detected the same problem as one that drops out mid-set?
No. Never being detected is a cable, permission, or exclusive-access problem. Dropping out after working fine is a radio, power management, or interference problem, and it has its own separate guide.