grandMA3 MIDI Remotes: Gamepad as a Walkabout Surface

Let us start by disagreeing with the premise most people arrive with. A game controller is not going to replace a grandMA3. It is not a console, it has no encoders, no executor rows, no command line and no display, and anyone telling you a sixty-dollar pad substitutes for a MA3 is selling something. What a gamepad is genuinely good at, in a MA3 world, is being a second surface — a wireless trigger you can hold while standing in the room looking at the actual light, firing executors and riding a master without walking back to the desk. That is a narrow use case and a real one, and MA Lighting's own MIDI Remotes implementation supports it properly.

What does grandMA3's MIDI Remotes system actually do?

It defines actions for incoming MIDI notes and Control Changes, binding them to console targets such as sequences, looks and specific faders.

MA's documentation describes the MIDI Remotes tab as the place to define actions for incoming MIDI notes or MIDI Control Changes. It sits inside the In and Out menu alongside DC Remotes, DMX Remotes, OSC, PSN and MVR — which tells you something useful about how MA thinks of MIDI: as one external control path among several, all of which feed the same assignment model.

That framing matters when you are planning. You are not "connecting a MIDI controller to MA3" in the way you connect a controller to a DAW. You are adding a remote input to a console that already has a canonical control surface, and the assignments you make are additions to a system of record, not a replacement for it. Design accordingly.

The assignment itself is done in the Assignment Editor, where both note and CC messages can be pointed at targets — sequences, looks and specific faders being the documented examples.

What hardware do you actually need?

A console or onPC station with a command wing, an I/O node or a third-party USB device, plus a MIDI-capable source and a standard MIDI cable.

MA's stated requirements are worth reading literally because they determine your whole topology. The phrase "third-party USB device" is the one that matters for most people building a gamepad rig — it is the route by which an ordinary USB MIDI interface gets you an input without buying MA hardware.

Two realistic topologies follow.

onPC on the same machine. If you are running grandMA3 onPC, the bridge can run on that same PC, create a virtual MIDI port, and feed onPC directly. Fewest moving parts, no cable, and the obvious choice for programming, pre-vis and small shows. The caveat is that you are adding software to a machine running a lighting application, so test it properly before a show rather than during one.

Separate machine into a console. On a real console the bridge runs on a laptop, the laptop's MIDI output goes out of a USB MIDI interface, and a standard MIDI cable carries it into the console's MIDI input. More hardware, but complete separation — nothing non-MA is installed on the desk, which is a policy many touring environments insist on and which is frankly good practice regardless.

If you need the controller to be wireless in the second topology, the wireless hop is laptop-to-controller over Bluetooth, not laptop-to-console. That is the right place for it; keep the MIDI cable wired. Wired versus Bluetooth covers what you are trading, and in a venue full of radios the honest answer is to run USB-C whenever you can.

Note, NoteAttack or Control — which should each input use?

Buttons use a note type, continuous controls use Control, and NoteAttack is the interesting middle case where velocity drives a fader.

MA documents that Note, NoteAttack and NoteAttackDecay are assigned to specific keys on a MIDI device, while the Control type is used where MIDI Control Change is sent. For the attack variants, the higher the attack value, the more a fader moves — meaning the velocity byte (0–127) directly influences how far the fader travels.

That last behaviour is unusually well-suited to a gamepad, because a gamepad has analog triggers. A bridge can derive a velocity value from how hard or how fast a trigger was pulled and send it as a note's velocity. On most hosts that is a novelty. On MA3, with NoteAttack, it means one trigger pull sets a fader to a position proportional to the pull — a single gesture that both fires and sets level. For a busked override that is genuinely elegant.

Control	MIDI	MA3 remote type	Target	Why
Cross	Note	Note	Executor GO	The most-used trigger on the most reachable button. Plain Note because a GO is a GO.
Circle	Note	Note	Executor OFF	Adjacent to GO so the pair is one thumb-roll apart.
Square	Note	Note	Flash a specific executor	A momentary action on a distinct shape.
Triangle	Note	Note	Goto cue / jump	Grouped with the other playback actions.
R2 trigger	CC	Control	Grand master or a specific fader	Continuous control on a continuous input. Spring return to zero makes the resting state unambiguous.
L2 trigger	Note with velocity	NoteAttack	A busking fader set proportionally	The attack value moves the fader, so one pull both fires and sets level.
Left stick Y	CC	Control	Executor fader 1	Continuous, with a physical centre you can feel.
Right stick Y	CC	Control	Executor fader 2	Second fader on the matching axis — two executors, two thumbs.
D-pad up / down	Note	Note	Executor page up / down	Paging is how a 14-control surface addresses a 90-executor console.
D-pad left / right	Note	Note	Previous / next cue	Navigation on the directional control.
L1	Note	Note	Shift layer (held, via the bridge)	MA3 sees different notes, not a modifier. The layering happens upstream.
R1	Note	Note	Blackout / grand master to zero	Must be reachable blind. Never place it next to anything destructive.

Paging on the d-pad is the key structural idea. A gamepad has roughly fourteen usable controls and a MA3 has far more executors than that, so you never try to map them one-to-one. You map a window and move the window.

How do you tell whether MIDI is reaching the console at all?

Enable Show MIDI Data in System Monitor and look, before you touch a single assignment.

MA documents this explicitly: to make the messages of the external MIDI device visible in grandMA3, enable Show MIDI Data in System Monitor, then open the System Monitor window and press keys on the external device. That is your first diagnostic and it should be your only one until it passes.

The reason this matters so much is that a gamepad rig has more places to fail than a hardware controller does. The chain is controller → bridge → virtual port → (optionally) USB MIDI interface → cable → console. System Monitor tells you in one glance whether the problem is upstream of the console or inside it, which collapses a six-link debugging problem into a two-link one.

If nothing appears in System Monitor, work backwards: is Enable Input on, is the cable in the right port, is the interface showing activity, does the virtual port exist on the bridge machine, is the bridge actually running. The missing-port decision tree covers the computer end of that chain, and the controller-not-detected triage covers the far end.

Where should a gamepad sit in a programmed show?

Strictly on the operator-discretion side of the line, never on anything that appears in the cue sheet.

This is the governance point and it is more important than any mapping advice in this article. A programmed show has a system of record — the cue list, the plot, the magic sheet — and the console is where that record lives. A second control surface that can also fire cues creates a second source of truth, and second sources of truth are how shows go wrong at the worst possible moment.

So draw the line explicitly and write it down:

• On the console only: anything called from the book, anything in the cue list, anything another operator would need to find in a handover, anything a tech rehearsal has signed off.
• On the gamepad: busked overrides, a walkabout GO while you focus from the house, a specials fader during a work session, effect intensity during a band changeover, anything explicitly marked as operator discretion.
• On neither: anything safety-relevant. Your blackout binding is a convenience; it is not a safety system and it must not be treated as one.

The strongest genuine use case is focusing and programming rather than performing. Standing under a rig with a controller in your hand, paging executors and riding intensities while looking at the actual light, is faster and better than walking back to the desk every thirty seconds. That is where a gamepad earns its place in a MA3 world, and it is a use case nobody sells hardware for.

For the theatre version of the same discipline — where the gamepad is the operator's surface and the cue stack lives elsewhere — see the theatre cue stack guide and QLab gamepad show control.

What about the OSC tab instead?

OSC is a supported input path in the same In and Out menu, and it is worth considering when you need finer resolution or network reach — with a caution about show networks.

The In and Out menu includes an OSC tab alongside MIDI Remotes, so grandMA3 can take OSC input as a peer protocol rather than an afterthought. For a gamepad the appeal is the same as it is everywhere else: floating-point values instead of 128 steps, named addresses instead of CC numbers, and no cable between the controller machine and the console.

The caution is specific to lighting. A show network carries sACN or Art-Net at high packet rates and is frequently under someone else's governance. Adding UDP control traffic to it is not a decision to make unilaterally fifteen minutes before a show — ask whoever owns the network, and if the answer is no, that is a reasonable answer. MIDI over a cable has the great virtue of being invisible to the network entirely.

OSC output from Universal Controller MIDI is a Pro-tier feature; the free tier covers one controller, one virtual MIDI port and three saved presets, which is a complete MIDI Remotes rig. The protocol trade-offs in general are in OSC versus MIDI from a gamepad.

What should you test before you rely on it?

Enable Input survives a restart, every assignment fires once, and the controller reconnecting does not require a console reboot.

• Restart everything in the order you will use on the day, and confirm MIDI still arrives without you touching anything. A setup that needs a manual step is a setup that will be forgotten.
• Fire every assignment deliberately with the console in a safe state. An assignment made and never exercised is a coin toss.
• Unplug and replug the controller with everything running. Find out now whether the bridge re-establishes the port cleanly and whether MA3 picks it back up. The handover sequence in the hot-swap guide is directly applicable.
• Check for stuck values. If a CC-mapped fader is left somewhere by a disconnect, know how you recover it from the console rather than from the controller.
• Battery, if wireless. Know your runtime; the battery benchmarks break it down per load profile, and a controller that dies mid-focus-session is merely annoying while one that dies mid-show is not.

What does the focus-session workflow actually look like?

One hand on the controller, standing under the rig, paging executors and riding intensity while looking at the light rather than at a screen.

This is the use case worth building for, so it deserves a concrete description rather than a general endorsement.

A focus session is slow, repetitive and physically distributed. You need a fixture at a level to see what it is doing, you need to change which fixture is live, and you need to do both while standing somewhere that is not the desk — under the truss, on the deck, at the back of the house checking sightlines. Traditionally that means either walking back to the console every thirty seconds, or having a second person at the desk calling and responding. Both are slow, and the second one costs a crew member.

With a controller in hand the loop collapses. D-pad left and right steps the fixture selection. R2 rides the intensity so you can see what you are looking at. A face button fires the look you are checking against. Another returns everything to a neutral state when you move on. You never turn around, and the time between "I want to see X" and seeing X drops from half a minute to half a second.

Build a dedicated focus map and keep it separate from any show map. They want different things — the focus map is all navigation and intensity, the show map is all executors and overrides — and trying to serve both from one layout produces something that serves neither. Save them as separate bridge presets; even the free tier's three slots covers a focus map, a show map and a spare.

One practical note: during a focus session the risk profile is low, so this is the right time to run the controller wirelessly and find out how the venue's radio environment behaves. Whatever you learn there tells you whether to trust Bluetooth later, and you will have learnt it when nothing was at stake.

FAQ

Can grandMA3 be controlled by MIDI?

Yes. The MIDI Remotes tab under the In and Out menu is used to define actions for incoming MIDI notes or MIDI Control Changes, with Enable Input switched on to allow external MIDI into the console.

Where is MIDI Remotes in grandMA3?

Press Menu, tap In & Out, and select the MIDI Remotes tab. That menu is divided into DC Remotes, MIDI Remotes, DMX Remotes, OSC, PSN and MVR tabs.

What hardware do I need for MIDI input on grandMA3?

MA Lighting lists a grandMA3 console or onPC station with a command wing, an I/O node or a third-party USB device, plus a MIDI capable device and a standard MIDI cable. An onPC station with a USB MIDI interface is the usual low-cost route.

What is the difference between Note, NoteAttack and NoteAttackDecay?

All three are assigned to keys on a MIDI device, but the attack variants use the velocity value — the higher the attack value, the further a fader moves — while a plain Note type acts as a straightforward trigger.

How do I see whether MIDI is reaching the console?

Enable Show MIDI Data in System Monitor, then open the System Monitor window and press keys on the external device. The incoming messages appear there, which separates a cabling problem from an assignment problem.

Should a gamepad replace a lighting console?

No. On a programmed show the console is the source of truth and the gamepad is a secondary trigger surface — useful for busked overrides, executor fires and a walkabout remote, not for anything on the cue sheet.

Can a gamepad control grandMA3 over OSC instead of MIDI?

The In and Out menu includes an OSC tab alongside MIDI Remotes, so OSC is a supported input path. OSC output from the bridge is a Pro-tier feature, and on a console you should confirm the network policy before adding UDP traffic to a show network.

Build the walkabout surface

The best reason to put a controller near a MA3 is to stop walking back to the desk. Download Universal Controller MIDI, get Show MIDI Data confirming messages arrive, and map one executor GO to one button — the rest follows quickly once the chain is proven.