MIDI troubleshooting goes badly because people debug in the wrong order. The instinct is to reinstall a driver; the actual cause is usually that the DAW built its device list before the port existed. This guide is a decision tree for the three faults that eat the most time — port not appearing, device busy or in use, and duplicated notes — with the exact operating-system commands that tell you which side of the chain is broken before you touch anything.
- Split the problem first. Does the OS see the port? If yes, it is a host problem; if no, it is a port problem.
- Port missing? Restart the DAW. It caches the device list at launch.
- Nothing arriving? You almost certainly enabled the port as an output, not an input.
- Device busy? Another app holds it exclusively — or you are on an old single-client hardware driver.
- Doubled notes? Two routes to the same track. Disable one.
First: does the operating system see the port?
Check at the OS level before touching the DAW, because this single question splits every MIDI fault into two completely different investigations.
# macOS — every CoreMIDI source and destination
system_profiler SPMIDIDataType
# macOS with SendMIDI installed
sendmidi list
# Linux — every ALSA sequencer client and port
aconnect -l# Windows — does the device object exist and is it healthy?
Get-PnpDevice -Class MEDIA | Where-Object FriendlyName -like "*Universal Controller*"
# Is the virtual MIDI driver service running?
Get-Service | Where-Object Name -like "*teVirtualMIDI*"Port listed? The plumbing is fine. Everything below the "host-side faults" heading applies. Port not listed? Skip straight to the port-side section — no amount of DAW configuration will conjure a port that does not exist.
Why is my MIDI port not showing up in my DAW?
The most common cause is that the DAW enumerated its MIDI devices at launch and the port was created afterwards, so quitting and relaunching the DAW fixes it more often than any driver change.
Work this list top to bottom. It is ordered by frequency, not by sophistication:
- Restart the DAW with the port already live. Start the bridge or port manager first, then the host. Reaper and Bitwig expose a rescan button; Logic and Ableton generally want a restart.
- Check the input side. In Ableton the port needs Track ON (and Remote for MIDI mapping). In FL Studio select the port under Input and click Enable — selecting it is not enabling it. In Reaper, right-click → Enable input.
- Look for a name collision. Two ports with the same name — one stale, one live — are indistinguishable in a dropdown, and you will pick the wrong one repeatedly. Delete the dead one.
- On macOS, confirm IAC is actually online. Audio MIDI Setup → Window → Show MIDI Studio → double-click IAC Driver → tick Device is online. It ships disabled and can switch itself off across logout.
- On Windows, confirm the driver installed. Status Error on the device object means the install was interrupted or blocked, commonly by endpoint-security software. Repair steps are in the teVirtualMIDI guide.
- On Linux, confirm the sequencer is loaded.
lsmod | grep snd_seq; load withsudo modprobe snd_seqif empty.
The port exists but nothing arrives — why?
Check that the port is enabled on the input side rather than the output side, and that the receiving track is not filtered to a MIDI channel the source is not transmitting on.
Those two account for most of this category, and both produce the same deceptive symptom: a port that is present, selected, and apparently connected to nothing. The direction mix-up is especially easy because many hosts list the same port in both columns. Your DAW is the reader. If you enabled it as an output, you have pointed the DAW's MIDI out at the bridge, which does nothing useful.
Then confirm bytes are moving, at the OS level, rather than guessing:
# Linux — live dump of everything on the port
aseqdump -p "Universal Controller"
# macOS — fire a known-good probe note into the bus
sendmidi dev "UCM Bus" on 60 100
sleep 0.5
sendmidi dev "UCM Bus" off 60 0Events visible here but silence in the DAW means the fault is downstream: track not armed, wrong input selected on the track, monitoring off, or an instrument that is not loaded. Nothing visible means the fault is upstream in whatever should be writing to the port.
What does the "MIDI device busy" error mean?
Another application has opened that port exclusively — older hardware drivers allow only one client at a time, so closing the other MIDI application or switching to a multi-client virtual port resolves it.
| Symptom | Likely cause | Fix |
|---|---|---|
| Port in use by another application | Exclusive claim by a single-client driver | Quit the other MIDI app, or route via a multi-client virtual port |
| Works in one DAW, fails in the second | First DAW holds the device | Use a virtual port both can read, not the hardware device directly |
| Busy even with nothing open | Orphaned process still holding the handle | Check for a background instance and quit it; restart if needed |
| Fails only after sleep or a USB replug | Stale handle from before the device re-enumerated | Quit the host, replug the device, relaunch |
| Fails only on a work laptop | Driver blocked by endpoint security | Reinstall elevated, or use a user-level loopMIDI port |
The structural fix for the recurring version of this is to stop pointing two hosts at a hardware device and point them both at a virtual port instead. Virtual ports on all three platforms are multi-client by design — see routing one controller into two DAWs.
Why am I getting duplicated MIDI notes?
The same source is reaching the track by two routes at once, typically a specific port plus an aggregate such as "All MIDI Inputs", or two separately enabled ports carrying the same stream.
Check these in order:
- Aggregate inputs. Cubase and others offer an "All MIDI Inputs" style device. If the track is set to that and you also enabled the specific port, every note arrives twice. Pick one.
- Two enabled ports, one stream. If the source writes to both its own port and an IAC bus, and the DAW listens to both, you get doubles. Disable one input.
- Echo back from the host. MIDI thru or a track echoing its input back out into a port that loops around. Turn thru off on the track.
- Duplicate control-surface script. A control-surface or remote-script slot pointed at the same port as a normal track input will act on the message a second time.
- Two instances of the sending app. Easy to do on Windows after an installer restart. Check the task list for a second process.
Why did my port disappear after a restart?
Ports published by an application exist only while that application runs, so the port returns when you relaunch it, whereas driver-created ports such as IAC buses or loopMIDI ports persist.
That distinction catches people out when they build a DAW template around a port name. If the template references a port that only exists when a particular app is running, opening the template without that app leaves every mapping unbound, and some hosts quietly discard the assignments rather than remembering them. If you need a permanent name, create a driver-level bus — an IAC bus on macOS, a loopMIDI port on Windows — and route the app into it. On Linux, connections are runtime state too; see the systemd persistence recipe.
Platform-specific gotchas worth knowing
Each operating system has one or two failure modes that look like a general MIDI fault but are entirely local to it.
- macOS: IAC's Device is online can untick itself across logout, and a plist owned by another user account prevents the setting from sticking.
sudo killall coremidiserverclears a confused CoreMIDI state. - Windows: endpoint-detection agents block driver installs routinely on managed machines. The symptom is a port that never appears even after a reinstall — details and
pnputilrepair commands in the Windows virtual port docs. - Linux: a controller that is invisible to the bridge is usually a permissions problem, not a MIDI problem. Without a udev rule the
hidrawnode is root-only. Rule and reload commands are in the Linux install docs. - All platforms: Bluetooth adds its own failure surface on top of everything above. If the controller link itself is dropping, start at Bluetooth troubleshooting instead.
The ten-minute diagnostic routine
Run these six checks in order and you will have isolated almost any MIDI fault before you start changing settings at random.
- Does the OS list the port? (
aconnect -l/sendmidi list/Get-PnpDevice) - Was the port created before the DAW launched?
- Is it enabled on the input side in the host?
- Is the receiving track set to all MIDI channels?
- Does
aseqdumpor a probe note show traffic? - Is there exactly one route from the source to that track?
Frequently asked questions
Why is my MIDI port not showing up in my DAW?
The most common cause is that the DAW enumerated its MIDI devices at launch and the port was created afterwards, so quitting and relaunching the DAW fixes it more often than any driver change.
What does the MIDI device busy or in use error mean?
Another application has opened that port exclusively — older hardware drivers allow only one client at a time, so closing the other MIDI application or switching to a multi-client virtual port resolves it.
Why am I getting duplicated MIDI notes?
The same source is reaching the track by two routes at once, typically a specific port plus an All MIDI Inputs style aggregate, or two enabled ports carrying the same stream.
My virtual MIDI port exists but nothing arrives — what now?
Check that the port is enabled on the input side rather than the output side, and that the receiving track is not filtered to a MIDI channel the source is not transmitting on.
Why did my MIDI port disappear after a restart?
Ports published by an application exist only while that application runs, so the port returns when you relaunch it, whereas driver-created ports such as IAC or loopMIDI buses persist.
Why does FL Studio still show the old MIDI port name?
FL Studio caches MIDI port names aggressively, so after renaming a port you need to restart FL Studio and use Rescan MIDI devices in Options before the new name appears.
If you are starting from scratch
Most of these faults are avoidable with one habit: create the port, verify it at the OS level, then open the DAW. Everything else follows from that order.
And if the source you are wiring in is a game controller, download Universal Controller MIDI — it creates the port for you on macOS, Windows and Linux, and ships a diagnostics view so you can see events leaving the bridge before you start blaming the host. Next: how to create a virtual MIDI port or the loopback verification test.