Search for how to turn a game controller into a MIDI controller and the top results send you to a three-program chain: something that turns the controller into keystrokes, Bome MIDI Translator to turn those keystrokes into MIDI, and something that creates a virtual MIDI port for the result to travel on. It works. People have shipped real shows on it. It also quietly destroys the most valuable thing a gamepad has, and almost nobody mentions that up front — which is why a Bome MIDI Translator alternative is worth looking at before you install anything.
- The classic chain: gamepad → keystroke utility → translation engine → virtual port driver → DAW. Three installs, three configs.
- What it costs: every analog value. A keystroke is binary, so triggers and sticks arrive as on/off.
- The alternative: read the controller through the OS game-input API directly and emit MIDI. One install, analog preserved.
- Not a hit piece: translation engines are excellent at rewriting MIDI that already exists. Use both, in the right order.
Why does the usual gamepad to MIDI recipe need three programs?
Because each tool in it only covers one hop, and none of them was designed for this problem in the first place.
Here is the chain as it is usually described on forums:
Every arrow in that diagram is a place things can go wrong, and every box is a separate application that has to be running, in the right order, with the right configuration file loaded. Start the DAW before the virtual port exists and the port is invisible. Lose focus on the wrong window and the keystroke layer sends your transport commands into a browser. Update one tool and another stops seeing it.
None of that is a criticism of the tools. It is what happens when you assemble a specific solution out of four general-purpose parts.
What do you lose by routing a gamepad through keystrokes?
The analog values — which is to say, the reason to use a gamepad instead of a computer keyboard in the first place.
A keystroke is binary. The key is down or it is up. There is no "the W key is 73% pressed". So when a utility converts your controller to keystrokes, it has to threshold every continuous input: the trigger becomes pressed-or-not at some crossover point, the stick becomes four directional keys, and all the resolution in between is discarded before any MIDI software ever sees it.
Concretely, here is what survives and what does not:
| Controller input | Through a keystroke hop | Read directly |
|---|---|---|
| Face buttons | Fine — they were binary anyway | Fine |
| D-pad | Fine | Fine |
| Analog trigger | Collapses to on/off at one threshold | Full continuous range to a CC |
| Analog stick | Collapses to four direction keys | Two continuous axes to two CCs |
| Touchpad / trackpad | Typically becomes mouse movement | Absolute XY coordinates to two CCs |
| Gyro / accelerometer | Not represented at all | Continuous motion axes to CCs |
| Velocity ride from a trigger | Impossible | Standard technique |
Look at the first two rows and you can see why the recipe gets recommended so confidently: for somebody who only wanted four buttons to launch four clips, it genuinely works and nothing is missing. The problems start the moment you want a filter sweep.
Is there an alternative to Bome MIDI Translator for gamepads?
Yes — read the controller through the operating system's own game-input API and emit MIDI from the same process, so the analog values never get thresholded.
That is what a purpose-built bridge does. On Windows it talks XInput or GameInput, which hand over 16-bit stick axes and 8-bit trigger values. On macOS it uses Apple's GameController framework, which pushes input changes via callbacks and knows about Xbox, PlayStation, Switch and MFi controllers natively. On Linux it reads evdev event devices. Then it writes MIDI straight into CoreMIDI, WinMM or ALSA.
The practical differences that follow from that one architectural choice:
- No keystroke hop, so triggers and sticks stay continuous and can drive CCs properly.
- No window focus dependency, because nothing is pretending to be a keyboard. Click into a browser mid-set and the MIDI keeps flowing.
- No separate virtual port driver on Windows, because the bridge registers its own port at install time — loopMIDI becomes optional rather than required.
- Deadzones, curves and calibration live where the raw data is, which is the only place they can be applied without compounding quantisation error.
- One application to start, one config to save, one thing to debug.
The trade-off is specialisation: a bridge reads controllers and emits MIDI, and that is all it does. If your problem is not a controller, it is not the tool.
Is Bome MIDI Translator still worth using?
Yes, genuinely — for rewriting MIDI that already exists, it is in a different class from anything a controller bridge does, and the two are complements rather than competitors.
A translation engine is a rules system. It takes incoming events, matches them against conditions, and emits whatever you tell it to. That is the right architecture for problems like: remapping a hardware controller whose firmware you cannot change, building complex conditional logic where one message's meaning depends on another's state, rewriting SysEx, bridging MIDI into applications that have no MIDI support by sending them keystrokes instead, or running headless on dedicated hardware so a show does not depend on a laptop.
A controller bridge does none of those things. What it does is the one hop a translation engine cannot do without help: getting a game controller's raw analog state into the MIDI world in the first place.
So the sensible architecture when you need both is to chain them in that order:
[ gamepad ] → [ bridge ] → virtual MIDI port → [ translation engine ] → [ host ]
▲ ▲
analog preserved here conditional logic hereThe bridge handles the hardware and keeps the resolution; the translation engine handles the clever rules. Nothing is thrown away and each tool does what it is actually good at.
What about GlovePIE, JoyToKey and the Max/MSP route?
JoyToKey still does its job, GlovePIE has not been maintained in many years, and the Max or Pure Data route is excellent if you were going to be in Max anyway and a strange amount of work if you were not.
- JoyToKey — Windows, turns controllers into keyboard and mouse input. Solid and still updated, but it is on the keystroke side of the problem, so the analog loss above applies in full. The JoyToKey alternative write-up goes through that trade in detail.
- GlovePIE — a scripting environment from the Wii Remote era that could do remarkable things. It has not seen meaningful maintenance for a long time and running it on a current Windows install is an adventure. Historically significant, not a recommendation — see the modern GlovePIE alternatives.
- Max/MSP — the
hiobject reads human-interface devices directly, so you get real analog values and total freedom over what you do with them. If you already live in Max, build the patch. If you do not, you are learning an entire environment to avoid an install. - Pure Data — same idea with a third-party HID external, free, and more fiddly to get running across platforms.
- WebMIDI in a browser — the Gamepad API plus WebMIDI genuinely works and needs nothing installed, which is a real advantage for a quick experiment. It is covered in the browser-only gamepad rig, along with the caveats about tab focus and background throttling.
Do I still need loopMIDI or the IAC Driver?
On Windows, not for this — the bridge registers its own virtual MIDI port, so loopMIDI becomes an optional extra rather than a prerequisite. On macOS you still enable the IAC Driver, because that is how CoreMIDI does virtual buses.
The macOS step is thirty seconds: Audio MIDI Setup → Window → Show MIDI Studio → double-click IAC Driver → tick Device is online. The icon goes from greyed out to full colour, which is your confirmation. On Linux the equivalent is an ALSA sequencer client, which the bridge creates and you can verify with aconnect -l.
If you want several independent ports — one per controller, or one per DAW when you are fanning out to multiple hosts — loopMIDI is still a perfectly good way to create them on Windows. There is a full breakdown of how each OS implements virtual MIDI in the virtual port explainer.
Frequently asked questions
Why does the usual gamepad to MIDI recipe need three separate programs?
Because each tool only covers one hop — one utility turns controller input into keystrokes, a translation engine turns keystrokes into MIDI, and a virtual port driver carries that MIDI to your DAW — so a general-purpose chain needs all three.
What do you lose by routing a gamepad through keystrokes?
Every analog value, because a keystroke is binary — a trigger that reports a continuous range becomes a single on and off event, so filter sweeps, expression and velocity rides are all impossible through that path.
Is Bome MIDI Translator still worth using?
Yes, for what it is designed to do — rewriting MIDI that already exists, conditional routing, SysEx work and sending keystrokes into applications that have no MIDI support at all — it is a genuinely strong tool and a bridge complements it rather than replaces it.
Do I still need loopMIDI?
Not with Universal Controller MIDI on Windows, because the bridge registers its own virtual MIDI port at install time, though loopMIDI remains useful if you want extra independent ports for other routing.
What about GlovePIE or JoyToKey?
JoyToKey still works for turning a controller into keystrokes on Windows and GlovePIE has not been maintained for many years, but both sit on the keystroke side of the problem and so both discard analog values.
Pick the tool that matches the hop
The question is not which program is better. It is where in the chain your problem lives. If you are rewriting MIDI that already exists, use a translation engine and use it properly. If your problem is that a controller is not MIDI yet, solve that hop directly instead of laundering it through keystrokes and losing every analog value on the way.
Download Universal Controller MIDI, point your host at the port, and keep the sweeps.