disguise Designer + Gamepad: Building a MidiDevice Surface

disguise is not VJ software and it is important to start there, because the mapping advice that works for Resolume will get you in trouble on a media server driving a stadium. disguise Designer is a show-control environment built around a timeline, and the timeline is the authority — cues exist in a known order, timecode is frequently the master, and the operator's job is often to let the system run rather than to play it. A game controller still has a real and useful place in that world. It is just a narrower one, and the architecture is deliberately different: disguise does not have a MIDI Learn button, it has a device model where you build a virtual replica of your control surface and then assign it.

How is disguise's MIDI model different from everything else?

You describe the control surface to Designer as a device before you map anything, rather than learning messages one at a time.

Nearly every other application in this space has a learn-based workflow. Click the parameter, move the control, done. disguise's MIDI Device model inverts that: you create a device, you define what controls it has, you set their types and modes, and only then do you assign those controls to layer properties and cues.

That feels like more work on day one and considerably less on day thirty. The reason is documentation. A learned mapping is invisible — it exists as a set of bindings scattered across parameters, discoverable only by clicking everything. A device definition is a declared object. It can be inspected, reasoned about, and handed to the next operator. In a world where shows get handed over between crews and where a project file might be opened by somebody who was not in the room when it was built, that is the correct trade.

Designer ships three pre-built control surfaces — the Behringer BCF 2000, M-Audio Oxygen 8 and M-Audio UC-33 — which tells you both that disguise expects you to use documented surfaces and that the list has not grown recently. For everything else, including every gamepad ever made, you create a MidiDevice and build the replica yourself, following the device creation process.

What does building the virtual replica involve?

Set the MIDI ports, add control sets, define control types, create one control per physical input, and set each one's data direction.

The documented sequence is: create the device by selecting MidiDevice from the device type menu; open the editor by right-clicking the device title bar and selecting edit; configure the MIDI ports by setting the midi in and midi out properties to your interface (with HDSP9632 noted for RME breakout cables and AOI Midi on newer systems); add control sets using the MidiControlSets manager to organise controls by function; define control types by right-clicking the type property and choosing dial, slider, button, keys or dial/button; add individual controls with the + button; and set the mode to in, out or bidirectional according to your data flow.

Three decisions in that list deserve thought rather than defaults.

Control sets. These are your organisational unit and the thing that makes a twenty-control surface readable at 2am. Group by function, not by physical location — a set called "playback" and a set called "layer overrides" beats a set called "left side of pad". You will be reading these under pressure.

Control type. Slider for analog triggers and stick axes, because they are continuous with a bounded range. Button for face buttons, d-pad and shoulders. Dial is for endless encoders, which a gamepad does not have, so skip it even though a stick superficially looks rotational — it is not an encoder, it is a bounded two-axis position sensor.

Mode. A standard gamepad has no LED grid and nothing meaningful to light up, so almost every control should be in only. Leaving unnecessary out or bidirectional paths enabled gives you a feedback channel you have not designed, which is a small risk for no benefit. If you want tactile confirmation, that is better handled by the bridge turning a MIDI message into rumble — see bidirectional MIDI and haptic feedback.

What should the surface actually contain?

Enough controls for the operator-discretion layer and nothing more — typically twelve to fifteen entries, not twenty-four.

Physical control	disguise control type	Mode	Assigned to	Why
R2 analog trigger	slider	in	Master brightness override	Spring return to a known end means the override always resolves rather than lingering.
L2 analog trigger	slider	in	Layer opacity override	Mirrors R2 so the two overrides are symmetrical across the hands.
Left stick X	slider	in	Content X offset	Nudging content position live while standing where you can see the screen.
Left stick Y	slider	in	Content Y offset	Pairs with X on one thumb for a complete position nudge.
Right stick X	slider	in	Colour or effect parameter	A second continuous axis for whatever this show's expressive parameter is.
Right stick Y	slider	in	Effect intensity	Paired with the above so one thumb shapes the whole effect.
Cross	button	in	Play / resume	The most-used transport action on the most reachable button.
Circle	button	in	Pause / hold	Adjacent to play, which is how every transport in history is laid out.
Square	button	in	Trigger a specific cue	One discretionary cue, explicitly marked as operator-fired in the paperwork.
Triangle	button	in	Return to a safe state	Your recovery action. Momentary, distinct shape, nothing destructive beside it.
D-pad up / down	button	in	Previous / next section	Navigation belongs on the directional control.
D-pad left / right	button	in	Previous / next track selection	Second navigation axis, orthogonal to the first.
L1	button	in	Shift layer (via the bridge)	Designer sees different notes, not a modifier — the layering happens upstream.
R1	button	in	Clear all overrides	One press returns everything on this surface to neutral. Build it before you need it.

The R1 binding is the most important row in that table. A surface full of overrides with no single way to clear them all is a surface that will eventually leave something engaged, and on a media server that is a visible fault in front of an audience. Design the exit before you design the entrances.

Where does a gamepad belong on a timecoded show?

On the operator-discretion layer only, never on anything the timeline or timecode owns.

This is the same governance line as on a lighting console, and it matters more here because disguise is often the thing generating timecode for everything else. Designer can be configured to send MIDI timecode based on the playhead position, which is how it drives cues on other devices such as lighting desks. When the media server is the master clock, a second surface that can also move the playhead is a genuine hazard.

Draw the line in writing:

• Timeline and timecode own: every structural cue, every section change in the running order, anything synchronised to music or to another department.
• The gamepad owns: overrides, nudges, brightness rides during a changeover, a single documented discretionary cue, and the clear-all that undoes them.
• Nobody owns from the pad: transport on a timecoded section. If the show is chasing timecode, the playhead is not yours to move and a button that moves it is an accident waiting for a moment.

disguise also documents MIDI Show Control setup and MIDI note setup for transport and section triggering, where notes can select tracks, trigger transport commands such as play, stop and next/previous section, or jump to particular sections. Those are powerful and they are exactly the capabilities to be disciplined about. Capable of is not the same as should.

Should the bridge run on the disguise server?

Almost never — put it on a separate machine and feed MIDI in over a physical interface.

Media servers are production hardware with controlled software images, often under support agreements that take a dim view of unsanctioned installs, and frequently rebuilt from an image between shows. Installing a bridge on one means your control surface disappears the next time the machine is re-imaged, and it means you are debugging a non-standard install under show pressure.

The clean topology is: controller connects to a laptop, bridge runs on the laptop, laptop's MIDI output goes out through a USB MIDI interface, physical MIDI cable into the server's MIDI input. Nothing non-standard touches the server, the surface survives a server rebuild, and if the laptop dies the show carries on exactly as it would have without a gamepad — which is the correct failure mode for a discretionary surface.

The same reasoning applies to other media servers, and we make the identical argument for Hippotizer in the Zookeeper guide. The hardware differs; the discipline does not. If your rig is a laptop-and-projector show rather than a server rig, this caution relaxes considerably — the MadMapper workflow is the right reference for that scale.

What are the specific failure modes to test for?

Stuck overrides, a surface that does not survive a restart, and a MIDI interface that enumerates differently after a reboot.

• Stuck override after a disconnect. If the controller drops while a slider-type control is mid-travel, the override stays where it was. Test this deliberately: unplug mid-ride and confirm your clear-all recovers it. If it does not, redesign before the show.
• Interface enumeration. A USB MIDI interface that comes back as a different device name after a reboot means the device's midi in property now points at nothing. Reboot everything once during setup and confirm the surface still works without intervention.
• Two sources on one port. Never let two applications send to the same MIDI path into the server. If you genuinely need two sources, use two ports; the fan-out pattern is in routing one controller into two hosts, and multi-port routing is a Pro-tier bridge capability.
• Stick drift moving a content offset. A drifting stick on a position override will slowly walk content off a surface over the course of a show, and nobody will notice until it is obvious. Deadzone at the bridge — the drift guide explains why that belongs upstream.
• Operator handover. Print the mapping table and tape it somewhere. A gamepad surface is unreadable from the outside, which is its one serious disadvantage against a labelled control surface in a professional environment.

Add one more test that is specific to discretionary surfaces: run a full show segment with the controller deliberately unplugged. If anything in the programme depends on it, you have put something on the pad that belonged on the timeline, and you have just found out in rehearsal rather than in front of an audience. A correctly scoped discretionary surface should be entirely absent from a show's critical path, and the only way to prove that is to remove it and watch.

How does this compare to the other media servers?

disguise asks for the most up-front structure and gives back the most documentation; Hippotizer and Notch sit at different points on the same trade-off.

It is worth having the comparison straight, because people arrive at media-server control from very different directions and the right answer genuinely differs.

disguise wants a declared device. You describe the surface, then assign it. High effort on day one, excellent legibility afterwards, and the right model for a show that will be handed between crews over a tour. If you only ever work alone on one project, the overhead feels unjustified; if you have ever inherited somebody else's show file, it does not.

Hippotizer leans on Multicontroller pages and pin nudging, which is a more immediate, more operator-facing model — closer to how a VJ thinks than how a programmer thinks. We cover that workflow separately in the Zookeeper guide, and the mapping philosophy there is deliberately looser than this article's, because the application's own philosophy is looser.

Notch is different again, because a Notch Block is a portable unit of behaviour rather than a show environment — you expose properties on the block and whatever hosts it drives them. That makes controller mapping a build-time decision rather than a show-time one, which is covered in Notch Block gamepad MIDI input.

The practical consequence for a controller rig: the same physical gamepad can serve all three, but the map should not be the same. On disguise it should be small, declared and discretionary. On Hippotizer it can be broader and more performative. On Notch it is really a property-exposure decision made inside the block. Resist the temptation to build one universal gamepad preset and carry it everywhere — the bridge's preset system exists precisely so you can keep a per-host map, and even the free tier's three preset slots covers a disguise map, a Hippotizer map and a rehearsal map.

FAQ

Can disguise Designer be controlled by MIDI?

Yes. The disguise MIDI Device can be used to trigger cues, automate properties and control Designer with standard MIDI messages from physical or virtual control surfaces.

Does disguise support my specific MIDI controller?

Designer includes pre-built control surfaces for the Behringer BCF 2000, M-Audio Oxygen 8 and M-Audio UC-33. For anything else, including a gamepad, you create a MidiDevice and build a virtual replica of the surface yourself.

How do you open the MIDI device editor in disguise?

Right-click the device title bar and select edit. That opens the editor where you set the midi in and out properties, add control sets, and define individual controls.

What control types are available on a disguise MidiDevice?

Right-clicking the type property offers dial, slider, button, keys and dial/button. For a gamepad, slider suits analog triggers and stick axes while button suits the face buttons and d-pad.

Should the controller go on the disguise server or a separate machine?

A separate machine, in almost every professional context. Media servers are production hardware with controlled software images, and feeding MIDI in over a physical interface keeps the server untouched.

Can a gamepad fire disguise cues?

Yes — the MIDI Device is documented as able to trigger cues as well as automate properties. On a timecoded show, keep the gamepad on operator-discretion actions rather than anything the timeline owns.

Does disguise do MIDI timecode as well?

Yes. Designer can be configured to send MIDI timecode based on the playhead position on the timeline, which is how it drives cues on other devices such as lighting desks. That is an output path and is separate from controller input.

Build the discretionary surface, not a second console

On a disguise rig the gamepad's job is the small set of things a human decides in the moment. Download Universal Controller MIDI, run it on a laptop beside the server, and build a MidiDevice with twelve controls and one clear-all.