Live production software is full of people reaching for a mouse at the exact moment they should not be. A cut lands late because the pointer had to travel. An overlay fires half a second after the graphic was needed. A fader ride turns into a drag that overshoots. vMix has supported MIDI shortcuts for years and most operators never use them, partly because the documentation treats MIDI as one line item among many, and partly because the obvious MIDI controllers are grid boxes that take up the desk space the operator does not have. A game controller solves the space problem and the one-handed problem at once — and vMix, usefully, does not care where the MIDI came from.
- Everything lives in Settings → Shortcuts. Enable the device with the MIDI Settings button, add assignments with Add — per the vMix shortcut documentation.
- Start order matters. vMix says the controller must be plugged in and on before vMix starts. Launch the bridge first.
- MIDIControlChange behaves as a fader; MIDINote behaves as a button. vMix detects which and treats them differently.
- Toggles are set by ticking the Value checkbox next to the MIDI note.
- Setup time: about 15 minutes to a working one-handed production surface.
What can a MIDI controller actually do in vMix?
Nearly anything the Shortcut system can reach, which in vMix is a very large surface indeed.
vMix's documentation states that shortcuts can be assigned to buttons, faders and knobs on any MIDI compatible device, with X-keys controllers supported automatically. That includes transitions, input selection, overlay channels, audio mute and gain, recording and streaming control, title field updates, playlist control, and replay operations — the controller options page notes that most MIDI and X-Keys controller buttons can be programmed to activate most functions in Instant Replay, and that jog and shuttle wheels work on supported devices.
The full list of functions is long enough that browsing it is genuinely worthwhile before you map anything — the shortcut function reference is the document to have open while you plan. Most operators map six things and never discover the other three hundred.
What matters for a gamepad specifically is that vMix distinguishes between two message classes. A control detected as MIDIControlChange works as a fader and adjusts the value automatically. A control detected as MIDINote works as a button, with the Value entered manually if the function requires one. That maps cleanly onto a controller: analog inputs should reach vMix as CC, digital inputs as notes.
Why does vMix not see the controller?
Because vMix enumerates MIDI devices at startup, and the documentation is explicit that the controller must be plugged in and turned on before vMix launches.
This is the single biggest gotcha in the entire vMix-plus-gamepad workflow and it catches everyone exactly once. With physical hardware the rule is easy to follow — the controller is plugged in, it is on, you start vMix. With a bridge creating a virtual port, there is a new failure mode: the port does not exist until the bridge creates it, so if vMix starts first, there was nothing to enumerate.
The fix is a start order, and you should make it a habit rather than a thing you remember. Bridge first, confirm the port exists, then vMix. On a production machine, set the bridge to launch at login so it is always up before anything else. If you have already made this mistake, there is no clever recovery — quit vMix, confirm the port, relaunch.
The second most common cause is a port that renamed itself between sessions, which makes vMix see a new, unconfigured device rather than the one you set up. Name the port explicitly and stop recreating it. Our virtual MIDI port guide covers the per-OS naming discipline, and on Windows specifically the teVirtualMIDI explainer covers the driver layer underneath most Windows virtual ports — worth reading, since vMix is a Windows application.
What is the right gamepad layout for a vMix operator?
Transitions and inputs on the face buttons, the transition fader on an analog trigger, overlays on the shoulders, and audio on a stick.
The design principle: anything that must happen at a precise moment goes on a button your thumb is already resting on; anything that is a ride goes on an analog control.
| Control | MIDI message | Target |
|---|---|---|
| Cross MIDINote Cut The most time-critical action in the entire programme belongs on the most reachable button. No travel, no hunting. | ||
| Circle MIDINote Fade Sits beside Cut so the two transition choices are one thumb-roll apart. | ||
| Square MIDINote Stinger 1 Your branded transition. Distinct shape so you never confuse it with a plain cut mid-show. | ||
| Triangle MIDINote Quick Play / preview-to-programme Grouped with the other transition family. | ||
| D-pad up / down MIDINote Preview input previous / next Navigation on the directional control. Lets you walk the input list without looking. | ||
| D-pad left / right MIDINote Select input 1 / input 2 directly Direct recall for the two sources you use most — usually a camera and a slide feed. | ||
| L1 MIDINote, Value ticked Overlay channel 1 toggle (lower third) Toggling is the documented behaviour when you tick Value next to the note. Lower thirds are states, not gestures. | ||
| R1 MIDINote, Value ticked Overlay channel 2 toggle (PiP) Mirrors L1 so the two overlay channels live under matching fingers. | ||
| R2 analog trigger MIDIControlChange Transition fader position A spring-loaded trigger is an unexpectedly good T-bar — it has real travel and always returns to a known end. | ||
| L2 analog trigger MIDIControlChange Master audio gain ride Proportional control for the one thing that most often needs a smooth hand rather than a click. | ||
| Left stick Y MIDIControlChange Input 1 audio fader Continuous, with a physical centre you can feel, for riding a presenter mic. | ||
| Right stick Y MIDIControlChange Input 2 audio fader Second source on the matching axis. Two mics, two thumbs. | ||
| Right stick X MIDIControlChange PTZ pan (where supported) A stick controlling a camera pan is the one mapping in this table nobody needs explained. | ||
| L3 (stick click) MIDINote, Value ticked Mute / unmute input 1 Click the fader you are already holding to kill the channel you are already riding. | ||
| Options MIDINote Start / stop recording Deliberately awkward to reach. You never want this hit by accident. | ||
That is fifteen production functions on one hand, with the other hand free for the mouse, the audio desk or the laptop trackpad. The one-handedness is the entire argument, and it is the same argument that applies to VJ controllers more broadly.
Is a gamepad better than a Stream Deck for vMix?
For continuous control it is not close; for labelled many-button recall the Stream Deck still wins, so most serious rigs end up with both.
vMix supports the Elgato Stream Deck through the vMix Shortcuts plugin, with live input thumbnails that update roughly four times a second. That thumbnail capability is genuinely excellent and a gamepad has no equivalent — if your show involves picking between twelve sources by sight, buy the Stream Deck.
But a Stream Deck has no faders, no sticks and no analog travel. Every button is a discrete press. Riding an audio level, running a transition manually, or panning a PTZ camera are all things it simply cannot do, and they are all things a gamepad does naturally. The honest division of labour: Stream Deck for recall, gamepad for ride.
There is also a redundancy argument that favours the gamepad. If your control surface dies fifteen minutes before a stream, a replacement gamepad is available in any electronics shop on earth. That is not true of specialist production hardware, and for a one-operator production it is a real consideration. The equivalent reasoning for streaming rigs generally is laid out in the gamepad-driven livestream rig, and the stinger-transition specifics in streaming with a gamepad.
How should you handle shift layers in vMix?
vMix shortcuts do not have a built-in modifier concept for MIDI, so build the shift layer at the bridge by sending different notes when a shoulder button is held.
This is an important architectural point and it differs from how Resolume or Millumin handle the same problem. In vMix, a shortcut is a direct binding from a specific MIDI message to a specific function. There is no "when L1 is held, Cross means something else" layer in the Shortcuts tab.
So the layering has to happen upstream. A capable bridge can send note 60 for Cross normally and note 72 for Cross while L1 is held, which vMix then sees as two entirely unrelated messages and binds to two entirely unrelated functions. From vMix's perspective there is no shift layer at all — there are simply more buttons.
That approach has a real advantage: it is completely host-agnostic, so the same shift layer works identically in vMix, OBS, Resolume and your DAW. It also has a real cost: the mapping table lives in the bridge, so you must document it somewhere the vMix operator can read. Write it down. The general pattern, including how to keep CC ranges from colliding, is covered in banks, layers and scoping — the host is different but the design problem is identical.
What about running vMix and a VJ application from one controller?
Give each application its own virtual MIDI port, and never let two applications listen to the same port.
This comes up constantly in hybrid setups — vMix handling the stream, Resolume or similar handling the screen content, one operator running both. The temptation is to point both at the same port and rely on different note numbers to keep them apart. Do not. Two applications on one port means every message reaches both, and every accidental collision is a live mistake.
The correct architecture is one named port per destination, with the bridge routing specific controls to specific ports. That is a multi-port setup, which is a Pro-tier capability — the free tier gives you one controller on one port with three saved presets, which is the right starting point for a vMix-only rig but not for a two-host one. The mechanics are in routing one controller into two hosts.
One more consideration for Windows production machines: virtual MIDI ports there sit on top of a driver, and a driver that has been upgraded, half-removed or installed twice is the usual cause of a port that exists but carries nothing. If you see that behaviour, start with the teVirtualMIDI guide rather than reinstalling vMix.
What should you test before going live?
Start order, every assignment once, the panic path, and a full disconnect-reconnect cycle.
- Start order rehearsal. Reboot the machine and bring everything up in your intended order. If the controller works after a cold boot without you thinking about it, the order is right.
- Every assignment, once, deliberately. Not a quick wiggle — actually perform each function and watch the programme output confirm it.
- The panic path. Know which single button takes you back to a safe state, and make sure it is not adjacent to anything destructive. Recording start/stop on a recessed button is part of that discipline.
- Unplug and replug. With vMix running, disconnect the controller and reconnect it. Find out now whether the shortcuts come back or whether you need a vMix restart, because you do not want to discover that mid-stream.
- Battery, if wireless. Run the show wired. A production is not a rehearsal and USB-C costs you nothing. If you must go wireless, know your runtime — the DualSense battery benchmarks have the numbers per load profile.
- A spare on the desk, charged. Hot-swap discipline is cheap insurance; the failover guide covers the handover sequence.
What does this unlock for a one-operator production?
It turns the single hardest problem in solo live production — being in two places at once — into a hand-position problem instead of a scheduling one.
Watch a one-person stream for ten minutes and you will see the same pattern repeatedly: something needs doing in the programme at the exact moment something else needs doing outside it. The guest's mic needs riding while a graphic needs firing. The camera needs a nudge while the chat needs reading. A slide needs advancing while the audio needs ducking. With a mouse, those are sequential — you do one, then the other, and the second one happens late.
A gamepad makes them concurrent, because the controller hand never leaves the controller. The mic ride lives on a stick, the graphic lives on a shoulder button, and both happen while the other hand is on the keyboard or the slide clicker. That is not a small improvement in comfort, it is the difference between a production that feels staffed and one that feels like one person doing their best.
The second, less obvious benefit is posture. A mouse-driven production pins you to a desk, facing a screen, for the duration. A controller lets you sit back, which over a three-hour stream is a genuine physical difference, and lets you look at the actual room or the actual guest rather than at a pointer. Operators who make this switch usually report the ergonomic change before they report the workflow one.
The cost is memorisation. A Stream Deck labels itself; a gamepad does not. Mitigate it the same way musicians do — keep the map small, keep it stable, and make the most important actions the most physically distinctive. Cut on Cross, panic on R1, and never move them. If you find yourself needing to look at a cheat sheet mid-show, the map is too big, not too unfamiliar. The same discipline applies across every host in this category, and it is laid out in more depth in the controller comparison.
FAQ
Does vMix support MIDI controllers?
Yes. vMix documents that shortcuts can be assigned to buttons, faders and knobs on any MIDI compatible device, and X-keys controllers are supported automatically as well.
Where do I set up a MIDI controller in vMix?
Open Settings, go to the Shortcuts tab, and click the MIDI Settings button to enable your device. Shortcuts themselves are then added from the same tab with the Add button.
Why does vMix not see my controller?
The most common cause is start order — vMix documentation states the controller must be plugged in and turned on before starting vMix. With a gamepad bridge that means launching the bridge and creating the virtual port first, then launching vMix.
What is the difference between MIDIControlChange and MIDINote in vMix?
If vMix detects the control as MIDIControlChange it works as a fader and adjusts the value automatically. If it detects a MIDINote it works as a button, with the Value entered manually if the function needs one.
How do I make a gamepad button a toggle in vMix?
When setting up a toggle shortcut on a MIDI control, tick the checkbox next to Value for the MIDI note. That is the documented route for toggling behaviour rather than momentary behaviour.
Can a gamepad replace a Stream Deck for vMix?
For continuous control, yes and then some — a Stream Deck has no faders, while a gamepad gives you two analog triggers and four stick axes. For labelled, readable, many-button recall a Stream Deck is still better, so the two complement each other rather than compete.
Can a gamepad drive the vMix transition fader?
Yes, with a SetFader-style function bound to an analog trigger or stick axis as a MIDIControlChange. A spring-loaded trigger is a surprisingly good T-bar substitute because it always returns to a known position.
Build the one-handed production surface
The whole point is getting your mouse hand back. Download Universal Controller MIDI, create one named virtual port, launch it before vMix, and put Cut on the button your thumb already rests on.