Show automation, Traktor mapping and DIY hardware.

This section closes the series with the most practical side of programming for technical artists: taking control as far as you need, beyond what factory software provides. Six units—MIDI translators, Traktor mapping, custom MIDI controllers, Arduino for MIDI: introduction, Raspberry Pi for show control: introduction and show automation—cover that journey on three fronts: rewriting messages, building hardware and orchestrating the entire show.

The three parts are connected. First decide which message you need, then whether to generate or translate it, and only finally which part of the show should be automated.

MIDI translators

A MIDI translator is an intermediate component between two devices, helping them understand one another. It receives a message, applies conditions, rewrites and forwards it: changing channel, number or value, dividing it into several messages or translating it into something not entirely MIDI, such as a keystroke.

Its value emerges in cases normal mapping cannot cover. A translator can condition a message according to system state, chain three outputs from one input, attenuate values to avoid sudden jumps or send the same command to two programs at once. Because almost all such programs work with activatable presets, you can change the entire behaviour with one button.

The usual mistake is starting here: adding a translator when the software already had sufficient mapping. The criterion: if the message exists and only needs moving, map it; if it needs logic, translate it. The industry’s reference tool and its project, translator and rule model are explained in Bome as MIDI middleware.

Traktor mapping

Traktor mapping means solving the problem within the first layer: Controller Manager. Create input assignments—you move hardware and software responds—and output assignments—the software returns state to the hardware, lighting its LEDs—choosing the port for each assignment and checking which messages remain unassigned.

Two resources turn basic mapping into effective mapping. The first is modifiers: states changing the meaning of the same buttons, so one key triggers a hot cue with a modifier active and an effects layer without it. The second is I/O discipline: no loose assignments without an output port, or the controller stays dark and you end up watching the screen.

If you have mapped other programs, the thinking is the same and the names change: look first at how Controller Manager works, then design your own mapping methodically, as explained in designing a mapping from scratch.

Custom MIDI controllers

Custom MIDI controllers means building hardware that does not exist. Instead of adapting a commercial controller, decide its surface, knob count, layout and behaviour, and build something responding exactly to your way of working.

The route is usually the same. Define the use—what you operate and how often—choose the inputs actually needed, build with standard components—potentiometers, encoders, LED push buttons—and program the board to send MIDI. The physical side is easy to learn; which messages emerge decides whether it is useful, bringing in everything from the series’ first guide.

To be worthwhile, DIY must solve something the market does not: fewer buttons, more knobs, a format fitting the case or custom behaviour. If your commercial controller can be made to do it through mapping, build nothing. The complete process is in the guide to building a MIDI controller.

Arduino for MIDI: introduction

Arduino is the most direct route to your own controller: a programmable board with a simple environment which, with the right library, speaks USB MIDI to the computer without unusual drivers. The board appears as another MIDI device, and you decide what message each pin sends.

The workflow is simple and repeats across projects. Read an input—a potentiometer value or button state—decide the corresponding message and send it. Decisions separating a toy from an instrument arise here: whether a control moves one value at a time or in ranges to avoid saturating the channel, whether a button sends a note or CC, whether there are status LEDs and, above all, whether code waits for a change rather than pumping messages at full speed.

Arduino’s MIDIUSB library documentation is the technical reference for that last step; the full build—board, surface and messages—is detailed in building a MIDI controller.

Raspberry Pi for show control: introduction

This is the other side of DIY: the computer rather than the board. A Raspberry Pi is a complete computer, small, inexpensive and low-power, which starts when powered and keeps running in the rack without a screen or keyboard.

That makes it the natural candidate for tasks that cannot depend on your laptop: keeping a MIDI translator alive, hosting an OSC server, serving a button panel or recording the show log. Build the system, install control software, start it automatically with the computer and finish the setup with remote access.

The limits are clear too. It is not a machine for demanding live audio or heavy visuals, and everything depending on it needs a reliable network and restart plan. Documentation, network configuration and startup are in Raspberry Pi’s official documentation; for the show-control side, the classic cue-and-trigger reference is QLab 5.

Show automation

Show automation is the layer joining everything above: the system executes repeated parts and those allowing no error. Automate a show by first writing the list—what happens, in which order and what triggers what—and then selecting the tool: a cue program, a panel with logic or a script in the software itself.

Reversibility is the discipline separating reliable automation from a house of cards: every action must be undoable or skippable without breaking the sequence, and anything depending on a state must degrade safely if that state arrives late. A panel showing only the happy path works until something fails; then you need to know what was automated and what remains in your hands.

Excessive automation is a risk too: if every gesture passes through three programs, diagnosing a live incident takes more effort than executing the show manually. Automate the repeatable and leave out what requires judgement.

Which route to choose for the problem

The table summarises the decision criterion. If the problem is software, map; if it is the message, translate; if it is hardware, build; if it is equipment reliability, set up the Raspberry Pi; if it is the show’s sequence, automate. Order matters: moving down the rows, each is more expensive to undo than the previous one.

Next step

This closes the Programming and advanced tools for technical artists series: messages, networks, creative environments and automation. Continue on the physical side with building a MIDI controller and designing a mapping from scratch; on the show-control side, synchronisation protocols are the next logical ground.