Blog macOS 9 min read

Gamepad to MIDI on a Mac: Any Controller, Any DAW

Turn any gamepad, flight stick or arcade pad into a MIDI controller on macOS. IAC Driver setup, GameController framework vs raw HID, the Input Monitoring trap.

By Aidxn Design

Search for a way to turn a gamepad into MIDI on a Mac and you land in a graveyard. MidiHID has not been touched in years. Fergo's JoystickMIDI is a Windows relic. Half the forum threads end with somebody suggesting you build a Max/MSP patch, and the other half end with nobody replying. Meanwhile macOS itself has two excellent, fully supported subsystems that do almost all the work — it just never connects them to each other. This guide covers what macOS actually gives you, where the gap is, and the handful of settings that cause ninety percent of the "it shows up but does nothing" problems.

TL;DR
  • Two macOS subsystems: GameController framework reads the pad, CoreMIDI's IAC Driver carries the MIDI. Nothing in the OS joins them.
  • The one-time setup: enable IAC Driver in Audio MIDI Setup, install the bridge, grant Input Monitoring if a generic pad reads zero.
  • Native support: Xbox, DualSense, DualShock 4 and Switch Pro on macOS 11+; Joy-Cons on macOS 13+; nearly everything else as generic HID.
  • Cost: free tier covers the port, default mappings and three saved presets; Pro is $89 one-time.

Does macOS have built-in gamepad to MIDI support?

No — macOS has first-class gamepad support and first-class virtual MIDI, and absolutely nothing that connects one to the other.

This surprises people because both halves are so good. Apple's GameController framework knows about Xbox pads, DualSense, DualShock 4, Switch Pro Controllers, Joy-Cons and the whole MFi ecosystem, handles pairing and battery reporting, and pushes input changes to apps via a callback instead of making them poll. CoreMIDI's IAC Driver is a virtual MIDI bus that has shipped with every Mac for twenty years and works flawlessly. But the only software that consumes GameController input is games, and the only software that consumes IAC MIDI is music apps, and the two populations never meet.

So the bridge's entire job is: subscribe to GameController callbacks (or raw HID, for devices the framework does not know), apply curves and deadzones, and write MIDI into CoreMIDI. There is no driver, no kernel extension, and no system modification involved, which is why this works cleanly on Apple Silicon and across OS upgrades that break older tools.

Signal flow diagram: Any controller to GameController / raw HID to The bridge to IAC Driver to Your DAW. Any controller USB or Bluetooth HID GameController / ra… macOS reads the pad The bridge curves, deadzones, MIDI IAC Driver CoreMIDI virtual bus Your DAW MIDI in
macOS supplies both ends of this chain. The bridge is the only link it does not ship.

What is the IAC Driver and do I need it?

The IAC Driver is Apple's inter-application communication MIDI bus, and yes, you need it on — it ships disabled by default, which is the single most common first-hour stumbling block.

Audio MIDI Setup  (⌘-Space → "Audio MIDI Setup")
  → Window → Show MIDI Studio
  → double-click "IAC Driver"
  → tick  ☑ Device is online
  → Ports: ensure at least one port exists (add one if empty)

The IAC icon in MIDI Studio is greyed out until you do this, which is the visual confirmation you are looking for — greyed means offline, full colour means online. Once it is on, every MIDI-capable app on the Mac can see the port, which is also how you route the bridge into more than one host at a time. The full background is in the virtual MIDI port explainer.

One thing worth knowing: the IAC Driver is a loopback, so if you enable both input and output of the same port in a host that echoes MIDI through, you will build a feedback loop and the host will choke. Enable the port as an input in your DAW, not as an output, unless you specifically want to send MIDI back to the bridge for haptics.

Why does my USB gamepad show up but send no values?

Input Monitoring. Devices read through raw HID rather than through the GameController framework need that privacy permission, and macOS grants it quietly rather than putting up an obvious prompt.

The symptom is distinctive and misleading: the device appears in the bridge's sidebar with the right name, so everything looks connected, but every axis reads zero and no button ever registers. You chase cables and drivers for an hour. The fix takes ten seconds:

System Settings → Privacy & Security → Input Monitoring
  → enable "Universal Controller MIDI"
  → quit and relaunch the app (the permission is read at launch)

Relaunching matters. The permission is checked when the HID session opens, so toggling it while the app is running changes nothing until you restart it. If the app is not in the list at all, drag it in with the + button.

Controllers that go through the GameController framework — Xbox, DualSense, Switch Pro and friends — do not need this permission, which is why a name-brand pad works instantly and the no-name USB pad from a drawer appears dead. Same cable, same port, different code path.

Which controllers work natively on macOS?

Everything mainstream, through the framework; almost everything else, through generic HID.

ControllermacOS pathConnectionNotes
Xbox Series X|S / One S / Elite 2GameController, macOS 11+USB or BluetoothThe Xbox Wireless Adapter dongle is Windows-only
DualSense / DualShock 4GameController, macOS 11+USB-C or BluetoothTouchpad and motion exposed too
Switch Pro ControllerGameController, macOS 11+BluetoothZL and ZR are digital, not analog
Joy-ConsGameController, macOS 13+Bluetooth, each half separatelyAxes are rotated 90° when detached
8BitDo padsDepends on mode switchUSB-C, Bluetooth or 2.4 GHz dongleStart the pad in its macOS mode — see below
Generic USB gamepadsRaw HIDUSBNeeds Input Monitoring; axes appear by number
Flight sticks, arcade sticks, racing wheelsRaw HIDUSBOften many more axes than a gamepad — great for CC work

The 8BitDo case is worth a sentence because it catches people out. Most 8BitDo Bluetooth pads boot into a protocol you choose with a button combination held at power-on, and the Mac-friendly mode is not the default. Holding Start + A at power-on puts the pad into its macOS/Android mode; the 8BitDo SN30 Pro guide walks through all four modes and what each one changes.

How do you map a controller the bridge does not recognise?

By axis number rather than by name — which looks broken and is actually the normal workflow for a generic HID device.

A recognised controller reports a known layout, so the bridge can say "left stick X". An unrecognised one reports a HID descriptor with numbered usages, so the bridge says "Axis 0", "Axis 4", "Button 7". Neither you nor the bridge can know which physical control that corresponds to without you moving it.

The workflow is five minutes of tedium, once:

  1. Open the input monitor and lay a notepad next to you.
  2. Move one control at a time and write down which numbered entry reacts. Do the sticks first, then triggers, then buttons in a consistent order.
  3. Watch for axes that sit at a non-zero rest value — some devices centre at half-range, some at zero, and a few report inverted.
  4. Map each numbered input to its MIDI destination, inverting axes where the direction feels backwards.
  5. Save the result as a preset so you never do it again.

Flight sticks and racing wheels are worth special mention here: they frequently expose six or more analog axes — throttle levers, rudder twists, hat switches, a clutch — which is dramatically more continuous control surface than a gamepad has. If you are building something that needs eight simultaneous CCs, a cheap second-hand flight stick is a better buy than a second gamepad.

Does this beat the old Mac tools?

The honest comparison is less about features and more about maintenance: the open-source Mac options in this space were written for a different macOS and most have not been updated through the Apple Silicon transition.

Tools like MidiHID were genuinely good in their day and were built against an IOKit-era HID API before the GameController framework existed and before Input Monitoring was a permission at all. The code is often still readable and still instructive, but running an unsigned, unnotarised, Intel-only binary on a current Mac means fighting Gatekeeper and Rosetta before you even get to the MIDI. If you are a developer and you want to build your own, those repos are a reasonable starting point and the GameController framework deep dive covers the modern API you would target instead.

If you are not building one, the things that actually matter day to day are the unglamorous ones: does it reconnect after sleep, does it survive an OS update, does it remember your deadzones, does it let you save more than one layout. That is what a maintained bridge buys you.

Troubleshooting checklist

  • No MIDI port in your DAW. IAC Driver is offline, or the DAW was launched before the bridge. Fix the first, then restart the second.
  • Device listed, all values zero. Input Monitoring permission, then relaunch the bridge.
  • Works in games, invisible to the bridge. Steam Input has claimed the controller. Quit Steam or disable its controller support.
  • Everything doubles. You have both the GameController and HID backends reading the same device. Pick one in the bridge's settings.
  • Reconnect after sleep fails. Remove the device in System Settings → Bluetooth and re-pair rather than toggling Bluetooth repeatedly.
  • Axis moves the wrong way. Invert it in the mapping rather than rewiring your brain.
  • Stick sends CC with nothing touching it. Drift. Raise the deadzone until the monitor is still — see the drift guide.

Frequently asked questions

How do you turn any game controller into a MIDI controller on a Mac?

Enable the IAC Driver in Audio MIDI Setup so macOS has a virtual MIDI bus, then run a bridge such as Universal Controller MIDI that reads the controller through the GameController framework or raw HID and emits notes and CCs on that bus.

Does macOS have built-in gamepad to MIDI support?

No. macOS has excellent built-in gamepad support through the GameController framework and excellent built-in virtual MIDI through CoreMIDI, but nothing in the system connects the two, which is the gap a bridge fills.

What is the IAC Driver and do I need it?

The IAC Driver is Apple's inter-application communication MIDI bus built into CoreMIDI, and enabling it gives you a virtual port that any two apps on the Mac can use to pass MIDI to each other.

Why does my USB gamepad show up but send no values on macOS?

Almost always the Input Monitoring privacy permission — devices read through raw HID need it, macOS grants it silently rather than prompting clearly, and without it every axis reads zero.

Which controllers work natively on macOS?

macOS 11 and later support Xbox Wireless Controllers, DualShock 4 and DualSense, and the Switch Pro Controller natively, and macOS 13 and later add Joy-Cons, while almost everything else works as a generic HID device.

Is there a free way to do this on a Mac?

The free tier of Universal Controller MIDI covers the virtual port, the default mappings for all supported controllers and up to three saved presets, which is enough for a working rig before deciding on the paid editor.

Three settings and you are done

IAC Driver online, bridge installed, Input Monitoring granted if you are on a generic pad. That is the whole macOS-specific part. Everything after it is mapping, and mapping is the fun bit.

Download Universal Controller MIDI for macOS, plug in whatever is nearest, and see what it sends.

Keep reading

More setup walkthroughs