Search for a REAPER bridge and you get three unrelated things: ReaRoute audio bridging, the VST bridging process that hosts 32-bit plugins, and the kind people actually mean when a gamepad is involved — software that translates a non-MIDI input device into something REAPER accepts. This article is about the third. It explains why the translation is necessary at all, what happens to the signal on the way through, and where to put the processing so that REAPER only ever sees clean, deliberate messages.
- The problem: REAPER accepts MIDI and OSC. A gamepad speaks USB HID. Those do not meet.
- The fix: a bridge reads HID reports and republishes them as a virtual MIDI port, OSC packets, or both.
- Where processing belongs: deadzones, curves and smoothing at the bridge; per-track shaping in a REAPER JSFX.
- Cost: bridge free to try,
$89for Pro. REAPER's side is free.
Why can REAPER not read a gamepad directly?
Because a gamepad is a USB HID device with a vendor-defined report format, and REAPER's input layer only speaks MIDI and OSC.
This is not an oversight. A DualSense sends a packed binary report containing stick axes, trigger pressures, button bitfields, gyroscope and accelerometer data, touchpad coordinates, battery state and more, in a layout specific to Sony and different again on Xbox, Switch Pro and 8BitDo hardware. Supporting that natively would mean a DAW maintaining a controller database — exactly the thing REAPER deliberately does not do for MIDI hardware either.
A bridge is the correct place for that knowledge. It owns the per-controller parsing, and everything downstream of it sees a single, boring, universal format.
What a bridge actually does to the signal
Four stages, in order, each of which changes what REAPER eventually receives.
1. Read
The bridge opens the HID device and reads input reports as they arrive. On macOS that path goes through Apple's GameController framework or raw HID; on Windows through GameInput, XInput or raw HID; on Linux through evdev and /dev/input/event*. The trade-offs between those backends are real and are covered in hidapi vs native gamepad drivers.
2. Normalise
Raw axis values differ by controller: different bit depths, different resting centres, different trigger ranges, inverted Y on some hardware. The bridge converts all of it to a consistent normalised form so your mapping does not have to know which controller is plugged in.
3. Shape
Deadzones, response curves, smoothing, latching, layer modifiers. This stage is why a bridge beats a thirty-line script: a resting stick on a worn controller sends constant small values, and without a deadzone that becomes a REAPER automation lane full of noise.
4. Emit
The shaped value is encoded as a MIDI message on a virtual port, an OSC packet to one or more targets, or both at once. From here on REAPER sees an ordinary controller.
What a virtual MIDI port is, and why it behaves differently per OS
A virtual MIDI port is an operating-system object that looks like a hardware MIDI interface to every application, but is fed by software rather than a cable.
The implementations differ enough to matter in practice:
| Platform | Mechanism | Setup needed |
|---|---|---|
| macOS | CoreMIDI, typically via the IAC Driver | Open Audio MIDI Setup, double-click IAC Driver, tick Device is online |
| Windows | A kernel-level virtual MIDI device installed by the bridge | None — no loopMIDI install required |
| Linux | ALSA virtual sequencer ports | Online by default; verify with aconnect -l |
The behavioural consequence that bites people: the port only exists while the bridge is running. Close the bridge and REAPER's input list has a dead entry. Start the bridge after REAPER and the port is not there at all until you hit Reset all MIDI devices in Preferences → Audio → MIDI Devices. Start the bridge first, every time, and the problem disappears. The full per-OS breakdown is in the virtual MIDI port deep dive.
Does a bridge add latency?
It adds one translation step and one virtual-port hop, both of which sit alongside much larger fixed costs you already have.
The chain from thumb to sound is:
- Controller polling interval — how often the hardware reports. Fixed by the device and the connection type; Bluetooth reports less often than USB.
- Bridge read and encode — the translation step.
- Virtual port delivery — an in-kernel or in-process handoff, not a cable.
- REAPER's MIDI handling — queued against the audio buffer.
- Audio buffer — usually the single largest contributor in the whole chain.
If responsiveness is not what you want, the productive levers are almost always the connection type and the audio buffer size, not the bridge. Use USB rather than Bluetooth for anything percussive, and set the buffer as low as your interface tolerates. The latency tuning docs walk through each stage.
Where should processing live — bridge, JSFX, or ReaScript?
Bridge for anything global, JSFX for anything per-track, ReaScript for anything that needs REAPER's own API.
| Job | Where it belongs | Why |
|---|---|---|
| Stick deadzone | Bridge | Physical property of the controller; should apply everywhere |
| Trigger response curve | Bridge | Ergonomic preference, not musical — same in every project |
| Shift layers / CC banking | Bridge | REAPER has no layer concept; it must arrive as different CCs |
| Per-track smoothing | JSFX | Lead synth and drum bus want different amounts |
| Scaling a CC to a musical range | JSFX | Belongs with the instrument, travels in the FX chain |
| Firing a sequence of actions | ReaScript | Only ReaScript can call REAPER's API |
| Reading the CC value inside a script | ReaScript | get_action_context() exposes the incoming value |
The failure mode to avoid is doing the same job twice. Smoothing in the bridge and in a JSFX gives you a control that feels sluggish and nobody can work out why. Pick one layer per job and write it down. The JSFX side is covered in depth in writing a REAPER JSFX that processes gamepad MIDI.
Keeping the bridge stable across sessions
REAPER bindings store a device name, a channel and a CC number. Anything that changes one of those breaks the binding silently.
- Freeze the mapping before you bind. Design the controller layout, save it as a preset, then do your REAPER learns against it. Edit the preset later and every binding made against it stops matching.
- Alias the device in REAPER. Double-click the port row in MIDI Devices and name it. The alias survives re-enumeration.
- Use a consistent connection. On Windows especially, a USB MIDI device can be enumerated differently on a different physical port.
- Keep one preset per purpose, not per session. The free tier stores three saved presets — a tracking map, a mixing map and an editing map is a genuinely complete setup. Pro removes the cap when you start building project-specific maps.
Download Universal Controller MIDI to get the bridge and the preset system, or buy Pro for $89 one-time for unlimited presets, conditional layers and OSC output.
One bridge, several destinations
A bridge is a fan-out, not a cable, and that is more useful than it first appears.
A virtual MIDI port can have multiple listeners, and OSC can target several host:port pairs at once. So one trigger pull can:
- Send a MIDI CC that REAPER records into an automation envelope.
- Send an OSC message to REAPER's control surface at float precision for the live ride.
- Send the same OSC to a visuals application on a second machine over the LAN.
That is the practical argument for a bridge over a one-off script: the translation layer is the right place to decide who hears what, and REAPER is just one of the listeners.
FAQ
What is a REAPER bridge?
In this context it is software that sits between a non-MIDI input device and REAPER, converting the device's native protocol into MIDI or OSC that REAPER understands. It is needed because REAPER has no direct HID gamepad input.
Why can REAPER not read a gamepad directly?
A gamepad communicates over USB HID with vendor-specific report formats. REAPER accepts MIDI and OSC, not raw HID, so something has to translate between the two.
Does a bridge add latency between the gamepad and REAPER?
It adds one translation step plus the virtual port hop. The dominant factors are the controller's own polling interval and your audio buffer size, both of which exist with or without the bridge.
Should the bridge or REAPER do the smoothing and curves?
The bridge, for anything you want to apply everywhere. Put per-track or per-plugin shaping in a REAPER JSFX instead, so it only affects that track.
Does the bridge need to be running every time I open REAPER?
Yes, because the virtual MIDI port only exists while the bridge is running. Start it before REAPER so the port is present when REAPER enumerates devices.
Can one bridge feed REAPER and another application at the same time?
Yes. A virtual MIDI port can have multiple listeners, and OSC can be sent to several host:port targets at once, so one controller can drive REAPER and a visuals application simultaneously.
Wrap-up
The bridge exists because two protocols do not meet, and it earns its keep because the translation point is also the right place for deadzones, curves, layers and fan-out. Get the port stable, freeze the mapping, start the bridge first, and REAPER stops knowing or caring that the controller was ever a gamepad.
Download Universal Controller MIDI and the translation is done for you.