There is a ceiling on MIDI mapping, and every VJ hits it eventually. You map a stick to a blur radius and it feels wrong, so you try a different parameter, and that feels wrong too, and eventually you realise the problem is not the mapping — it is that no built-in effect exposes the thing your hand wants to do. The parameter you need does not exist. That is the point where Resolume Wire stops being a curiosity for shader nerds and becomes the most practical tool in a controller-driven rig: a node-based environment where you build the effect around the control, rather than hunting for a control that suits the effect.
- Wire is a node-based programming environment for building Resolume effects, sources and mixers — per Resolume's own introduction.
- Compatible with Arena and Avenue from 7.4 up, with Resolume recommending the latest of both.
- The gamepad never touches Wire directly. You expose patch inputs, they appear as Resolume parameters, you MIDI-map those.
- The win: design parameters whose neutral value matches a stick's centre and a trigger's rest position, instead of fighting defaults that assume a mouse.
- Cost: Wire is a separate product on the Resolume shop; the bridge has a free tier covering one controller, one port and three presets.
What is Resolume Wire, in one paragraph?
Wire is a node-based patcher that produces custom effects, sources and mixers which then load into Resolume alongside the built-in ones.
Resolume describes it as "a node based programming environment to accompany Resolume" and "essentially a programming language for visual design", where connected blocks of code called nodes do the work. You patch nodes together, you compile, and the result shows up in Resolume as a normal item in the effect or source list — complete with whatever sliders, inputs and triggers you chose to expose. That last clause is the whole reason this article exists, because you choose the parameters, which means you can design them for a game controller rather than for a mouse.
The node system has four categories documented in Wire's node anatomy page: Input nodes that bring data in from outside Wire (including Resolume data, OSC and MIDI, and Syphon/Spout), Output nodes that send data out, UI nodes such as comments that document the patch without affecting it, and general nodes that do the actual processing of data, textures and arrays. Inlets sit on the left of each node, outlets on the right, and hovering shows you which data types will connect.
Why build a patch instead of mapping an existing effect?
Because built-in effect parameters were designed around a mouse dragging a slider, and a thumbstick is a fundamentally different object.
Three concrete mismatches come up over and over.
Neutral is in the wrong place. A slider's natural resting value is wherever you last left it. A thumbstick's natural resting value is dead centre, and an analog trigger's is zero. Most built-in effects put their "do nothing" state at one end of the range, so a centred stick means half an effect. If you build the patch yourself, you put the null point at 0.5 for a stick-driven input and at 0.0 for a trigger-driven one, and the controller's physical rest position becomes the visual rest position. That is not a cosmetic improvement — it means you can let go of the controller mid-set without the image changing.
One control should move several things. Riding a good-looking transition usually means three or four parameters moving together on different curves — a blur that ramps fast, an opacity that ramps slow, a hue shift that only engages past the halfway point. Mapping one stick to four Resolume parameters at once is not something the shortcut system does. Inside a patch it is four wires off one exposed input with different maths on each branch.
Curves. MIDI gives you 128 linear steps. A lot of visual parameters are perceptually logarithmic, so a linear sweep looks like nothing happens for half the travel and then everything happens at once. A patch lets you shape the response inside the effect, which beats trying to compensate at the controller.
How does a gamepad actually reach a Wire patch?
Through Resolume, not through Wire — the controller maps to the exposed parameters that your patch publishes into the Resolume interface.
The chain is worth stating explicitly because people assume it is more complicated than it is:
- Your controller sends HID reports to the bridge.
- The bridge converts them to MIDI notes and CCs on a named virtual port. (If you want the mechanics of that conversion, what a DualSense bridge actually does covers it.)
- Resolume receives that port as an ordinary MIDI input device.
- Your Wire patch exposes inputs, which Resolume renders as parameters on the effect.
- You MIDI-map the controller to those parameters exactly like any built-in parameter.
Nothing in Wire needs to know a gamepad exists. That is a feature, not a limitation — it means the patch is portable to anyone with any controller, and it means all the mode knowledge from Resolume's MIDI mapping modes applies unchanged. Absolute for analog inputs, note assignments for buttons, Toggle for states, Piano for gestures.
Wire's Input node category does include OSC and MIDI nodes for patches that want to listen directly, which is a legitimate alternative route. For most VJ work the Resolume-parameter route is better, because it keeps your mapping in one place and lets you reassign without reopening the patcher mid-tour.
Which inputs should you expose, and which should you not?
Expose only what you intend to physically perform, because every exposed input is another row to scroll past when you are mapping under pressure.
Wire's Expose Inputs feature turns numeric inputs and toggles into interactive elements that surface in Resolume. The temptation is to expose everything "just in case". Resist it. A patch with twenty exposed parameters is a patch you will never map properly, and an unmapped parameter is dead weight in an interface you are reading in the dark.
A good discipline: decide the physical controls first, then expose exactly that many inputs. If the patch is going to be driven by two triggers and one stick axis, expose three inputs. Everything else gets baked in as a constant. If you later want to adjust a baked constant you reopen Wire, which sounds annoying and is in fact the correct trade — it keeps the performance surface small and it stops you fiddling with parameters that should not change during a show.
What does a controller-shaped patch look like in practice?
Three exposed inputs, each with a resting value that matches a physical rest position, and all the interesting behaviour happening between them.
Here is a worked design for a single patch I would call a "pressure" effect — the sort of thing you want on a build-up. It is three exposed inputs doing the work of about eight parameters.
| Exposed input | Gamepad control | Resting value | What it drives inside the patch |
|---|---|---|---|
| Pressure | R2 analog trigger, CC, Absolute | 0.0 (trigger released) | Branches to three places on different curves: displacement amount rising steeply, saturation falling gently, and a hard-edge threshold that only engages above 0.7. One squeeze does the whole build. |
| Bias | Left stick X, CC, Absolute | 0.5 (stick centred) | Shifts the displacement direction left or right of centre. At rest the image is symmetrical, which is why the resting value must be the middle of the range, not the bottom. |
| Grain | Left stick Y, CC, Absolute | 0.5 (stick centred) | Cell size of the displacement field, scaled logarithmically so the perceptually useful range is spread across the travel instead of crammed into the top third. |
| Freeze | Square button, Note, Piano mode | Off | Holds the displacement field's random seed so the texture stops evolving. Momentary on purpose — a latched freeze is a stuck image waiting to happen. |
| Invert | Circle button, Note, Toggle mode | Off | A genuine state, so it latches. The only toggle in the patch, and deliberately on a different button shape from the momentary one. |
| (not exposed) | — | Fixed | Colour palette, edge softness, blend mode, noise octaves. All baked in. Changing them is a design decision, not a performance gesture. |
Note the shape of that table: five controls, five physical inputs, nothing orphaned. The patch is designed so that putting the controller down returns the image to a clean state automatically, because every analog input's rest position is also its null value.
How do you test a patch without a show to test it at?
Run it with your hands off the controller first, then with one input at a time, and only then with everything at once.
The failure mode of custom patches is that they look great while you are actively performing them and look broken the moment you stop. Test in this order:
- Hands off. Controller on the table, patch running. The image should look like a usable neutral state. If it does not, your resting values are wrong — fix the patch, not the mapping.
- One input, full travel, slowly. Watch for dead zones where nothing visible happens, and for cliffs where everything happens in five MIDI values. Both are curve problems inside the patch.
- One input, full travel, as fast as you can. This is where you find out whether the patch can keep up, and whether 128 MIDI steps are enough resolution for the gesture. If it steps visibly, consider OSC — Resolume supports OSC shortcuts with far finer resolution, and OSC output is a Pro-tier capability in the bridge. OSC versus MIDI from a gamepad lays out when it is worth the extra routing.
- Everything at once, for two full minutes. Patches that are fine for ten seconds sometimes drift, accumulate or blow out over time. Two minutes catches most of it.
- On the actual output. A patch that reads beautifully on a laptop screen can be invisible on a projector in a lit room. Check on the real surface before you commit it to a show.
Where does Wire beat TouchDesigner for this, and where does it lose?
Wire wins when the output belongs inside a Resolume composition; TouchDesigner wins when the patch needs to be the whole show.
These two get compared constantly and the comparison is usually unhelpful because they solve adjacent problems. Wire's output is a Resolume effect, source or mixer — it lives inside the composition, it respects the layer stack, it gets blended and mapped by Arena's output stage. That integration is the point. If your show is a Resolume show and you need one custom behaviour, building it in Wire is dramatically less work than rebuilding the surrounding infrastructure elsewhere.
TouchDesigner wins when the patch is the show: generative systems, data-driven visuals, sensor input, multi-machine synchronisation, anything where you need the full render graph rather than an effect slot. It also has a much deeper input vocabulary, including the OSC In CHOP and MIDI In CHOP for controller data, plus signal-shaping operators like Lag and Filter that have no direct Wire equivalent. We cover that route in TouchDesigner gamepad OSC show control and the MIDI CHOP mapping guide.
The pragmatic answer for most VJs: Wire for effects inside a Resolume set, TouchDesigner for the sets that are not Resolume sets.
What should you build first?
A patch with one exposed input mapped to an analog trigger, because it teaches you the whole workflow in twenty minutes.
Do not start with the ambitious one. Build a patch that does a single visual thing whose intensity is driven by one input, expose that input, load it, map it to R2, and perform it. You will learn more from that than from a week of reading, because you will immediately feel the two things that matter — whether the rest position is right and whether the curve is right — and both of those are patch-side problems that no amount of clever mapping fixes.
Once that works, the second patch almost builds itself, because you now know the shape. And the third one is where you start designing for the controller rather than adapting to it, which is the point of the whole exercise.
If you are not yet set up on the Resolume side at all, start with the Arena DualSense setup and make sure the port and preferences side is solid before adding a patcher to the stack. A patch is a lovely thing to debug; a patch plus a flaky MIDI port is not.
What are the three patches worth building first?
A pressure patch, a transition patch and a recovery patch — in that order, because each one teaches something the next depends on.
The pressure patch. One exposed input on a trigger, driving three or four things on different curves. This is the patch described in the table above and it is the right first build because it is a single gesture with an obvious success criterion: squeeze, and the image intensifies in a way that looks deliberate rather than like a slider moved. Everything you learn here — curves, null points, branching one input to several destinations — applies to every patch afterwards.
The transition patch. A mixer rather than an effect, with one exposed input driving the whole crossfade between two sources, including the things that should not be linear — a wipe that eases, a flash that only appears in the middle third, a blur that peaks at 50% and resolves at both ends. The built-in transitions are fine and generic; the point of building your own is that it becomes your transition, recognisable across a set. This is also where you learn why a trigger's return-to-zero matters: a transition that cannot be abandoned halfway is a transition you will eventually be stuck inside.
The recovery patch. Not glamorous and the one most people never build. A source or mixer that, on a single button press, resolves everything to a clean, known, projectable state. Not black — black looks like a failure — but something defensible you can sit on while you fix whatever just went wrong. Every working VJ eventually needs this and almost nobody has it, because it is the only patch you build hoping never to use.
Build those three and you have the skeleton of a set: a way to intensify, a way to move between things, and a way to get out of trouble. Everything after that is taste. The performance-side thinking behind that structure is covered in designing a repeatable residency set, which approaches the same problem from the other direction.
FAQ
What is Resolume Wire?
Wire is a node-based programming environment that accompanies Resolume, letting you build custom effects, sources and mixers from connected nodes rather than writing shader code. The resulting patches load into Arena and Avenue alongside the built-in effects.
Can a gamepad control a Resolume Wire patch directly?
It controls the patch through Resolume rather than inside Wire. You expose the patch inputs you want to perform, they appear as parameters in the Resolume interface, and you MIDI-map your gamepad to those parameters like any other Resolume control.
Do I need Wire to use a gamepad with Resolume?
No. A gamepad maps to every built-in Resolume parameter without Wire at all. Wire matters when the behaviour you want does not exist as a built-in parameter and you need to build it.
Which Resolume versions work with Wire patches?
Wire is compatible with Arena and Avenue from version 7.4 upward, and Resolume recommends keeping both on their latest versions. Check your version before building a patch you intend to depend on.
Is Wire a separate purchase from Arena?
Yes, Wire is listed as its own product on the Resolume shop alongside Avenue and Arena, with its own price. Check the shop page for current pricing in your region.
Should I expose every input in my Wire patch?
No — expose only what you intend to perform. Every exposed input becomes another parameter in the Resolume interface and another thing to scroll past when you are MIDI-mapping under time pressure.
Can a Wire patch send values back to the controller for haptic feedback?
Not directly from Wire. Feedback runs the other way through your bridge, which can take a MIDI message from Resolume and turn it into rumble or light bar colour — so design the feedback as a Resolume output, not as a Wire output.
Get the controller side sorted first
A custom patch is only as good as the hand driving it. Download Universal Controller MIDI, create one named virtual port, and get a stable mapping working against a built-in effect before you build your first patch — then the only variable left is the patch itself.