State Of Lux
Daryl Atkins - Art Director, Designer

Flux & Flex

MaxMSP Software & hardware development


The system was initially developed as a rudimental way of controlling a simple stage setup. I wanted to create something which was uniform & had an identity from venue to venue. Doing a bunch of smaller shows on the tour it was important to create a look and feel for the songs but without the overhead of taking a LD or additional tech out with us on the road. The system is custom built in Max MSP and utilises a DMX USB pro interface, a modded arduino, router, and an iPad.

Through experimentation and expansion, the system developed (and continues to develop) in to something more robust and flexible allowing for back line crew communication and a more immersive lighting system. Implementing TCP/UDP communication in Max between a rack-mounted arduino and remote iPads allowed for simple setup and testing of equipment with just one user. The idea was to make a system that was 100% flexible for expansion and reduction from venue to venue without the typical financial footprint and setup-time that is normally associated with a travelling lighting rig.

The first iteration I built as a hybrid lighting sampler and interface triggered by an SPD-SX drum module, which launched short midi sequences in the fLUX system. Max would align itself to the program change data on the drum machine and load the respective 9 midi samples, which in turn triggered programmed sectional lighting cues. These were programmed using a midi keyboard in logic while travelling on the first tour. This approach allowed flexible playing, looping and deviation rather than a traditional backing track approach which has little margin for flexibility (but is infinitely easier to play drums to!). The two CC controls on the drum machine also allowed mixing of hue and luminance output of the par fixtures for non-tempo based sections as well as a panic and ‘all on’ commands. Other conditional lighting samples could be triggered which activate procedural or code based patterns and chases.

The first stage setup was kept quite simple. We had a number of fluorescent tubes set up in an array of 8 upright fixtures which I rewired to IEC connectors running in to two 4 channel dimmer packs. This allowed the tubes to be programmed with chase and switched patterns. Three strobes were placed behind each member which were separately addressable and finally some par cans which initially worked on a uniform overall wash.

For the second tour the system had further developed to be housed inside a 12u 19′ rack flight case. This incarnation incorporated a wifi router mounted on the rear of the rack as well as housing the switch packs, the DMX output module & the rack server as well as all the internal cabling. This was quite a turning point as I found the first tour particularly nerve-racking due to the equipment & cabling being very vulnerable to damage from band changeovers and equipment being precariously stacked on top of switch packs and cabling. This made the setup infinitely more efficient and minimised any faults occurring from loose connections.

The third and current revision of the system substituted the 8 neons for 6 upright led bars, which makes a huge difference due the large choice of colour and chase patterns across the fixtures and also as segments of the fixtures themselves, which opens up a lot more creative opportunities. The system can now run headless with the arduino displaying vital information through a LCD readout, which gives piece of mind without having to have a monitor running on stage.

I’ve implemented a router mounted on the rear of the rack, which broadcasts a protected wifi network as well as allowing communication between the arduino and and external input and output devices.

The router operates on a fixed ip allowing MaxMSP to connect to a implicit address and port assignment via a UDP send and receive. This is initiated by a loadmess object on startup. The external devices currently run using touchOSC which is served an ip address for that device. Once connected to the network up to 4 satellite units can be added via the interface to receive fLUX data such as a visual metronome, track listing, and warning indicators. It also allows remote setup of lighting fixtures via an iPad.

The iPad works using the TouchOSC application once joined to the fLUX network. Fixture & playlist information is displayed on the interface, as well as the ability to test fire individual fixtures wirelessly around the venue, this is particularly useful when stress testing & fault finding any wiring problems during setup. We also had the ability from door time and during support acts to dim or switch to a static lighting look, and five minutes before our set, kill all house and fixtures to give a dramatic effect. We initially had a glitch setting during the opening drone which would loop until our stage time, which worked quite effectively. I have been looking at Xcode to displace this interface to something more suited to our needs as currently TouchOSC allows for a moderately limited customisation and implementation in this pipeline, specifically a text size limit for visual feedback while on stage (text can never be big enough).

The router works on a fixed IP closed network, MaxMSP and the arduino interacts via internally wired ethernet, and the iPad satellites via WiFi.

The most recent addition to the system is an arduino micro controller which is panel mounted to a custom routed blanking plate displaying an LCD and keypad for interacton. The ardunio communicates with Max via the router through ethernet, which in turn has an LCD and keypad attached, allowing setup and interaction via a rack panel itself. The idea was to run the Max servers headless, and displaying the current lighting scene and fixture information on the panel mounted LCD itself, rather than having a monitor at all. The keypad allows input from the panel for basic functions such as moving between tracks, forcing a blackout and lamp testing for setup of the system.

When the system boots, the display displays the ‘listening..’ screen until max creates a connection. Once connection is successful with the arduino and the first scene is loaded it moves to display the current lighting track, and simple fixture information.

The rack unit connects to a footswich via 1/4″ stereo jack to a two channel footswitch I made from a aluminium hammond case, with two simple footswitches, which echo the same functions as the left and right keypad buttons. As the fLEX system controls the drum machine program change, this allows me to advance through the playlist, via fLEX alone, rather than the drum machine. This is advantageous as it allows invisible control of the system and can correct any disparity between the lighting system and the drum machine itself in the unlikely event the drum machine became decoupled from fLEX.

fLUX was originally standalone, but its now governed by its older brother, fLEX. The fLEX module holds global information that is passed to fLUX but extends to bring in line external interfacing and control of the drum machine, as well as playlisting, tempo, and metronome configuration. It can also control external midi synchronisation for midi clocked devices (such as delays) if required. Its primary use is to playlist the set and pass tempo information to the cues that are triggered requiring time synced procedural patterns.

fLEX also incorporates an attendant mode, which offers a pallet of potential realtime communication options available to performers and crew. A menu of options can be flagged independently from any satellite unit connected to the FLUX wifi in the venue and will instantly jump to the front of the system, and highlighted to all users, until that message is untoggled by any user, once the information is acknowledged or resolved. This is certainly overkill in its practical use at this stage but certainly could be a useful tool for larger touring productions. If your act needs something similar i’m happy to work something out for you.

fLUX takes up the majority of the system resources, as well as the largest amount of (ongoing) development time. I am iteratively rewriting the system constantly to refine the way it works and also to expand the system to be more flexible and more robust. Im fairly new to MaxMSP (relatively speaking) so I’m constantly discovering an more elegant or less more resourceful method of doing something. Most of the system has been completely rewritten from the original version as I come across a bunch of eureka moments and decide to revisit some older modules.

The most major overhaul has been the migration from a fixed sample system to a flexible mixer cue, scene led approach. After spending time with the LD from the Biffy Clyro tour I learned a lot of lessons on how to approach flexible triggering and organisation of light shows. After this tour I went home and rewrote this approach entirely to allow the looks to be developed and modified inside fLUX, and relies very little on external sequencing other than cues to move between sections (rather than the previous method of explicit fixed sequencing).

As it currently stands, the system works by loading and cycling between a setlist of songs, which are created using an ‘add track’ dialogue. This fills the system with empty database information ready for programming. When a track is called it fetches the associated midi file for fully automated movement throughout the track. This then loads the sections in a scene list which is moved through sectionally through the song, highlighted in the scene lister, each of which can be named. Each scene has a bank of 10 faders, each named with a preset look, each fader can be mixed from 0-100% as well as bumped (useful for strobe or blinder stabs for example).

The patching window allows fixtures to be patched to explicit channels depending on their attributes, which then become available in the fader setup windows, this allows the patching to only have to be mapped once, and it will recurse across the system, as each value is routed at the end of the signal chain to the correct attribute.

In addition to the iPad a midi controller such as the BCD-2000 is an ideal cheap interface to get some physical control of the system. I had one lying around so I decided to implement this as it has potential as a manual controller and a way of quickly dialling in looks using the wheels, faders and rotary controls. Plus it provides the lowest latency method for really accurate triggering. (Wifi seems to occasionally suffer from a little bit of network saturation on long CC commands)

The newer models may have been somewhat improved, but as my model was one of the first generations I discovered a few difficult obstacles. I plugged the device in and probed the midi to see what the thing spits out. Unfortunately you can’t have any control over what notes are output for the desk so you have to bend your software to meet the BCD standards. The midi stream is a little noisy and the build quality isn’t great, but for the cost and dealing with MIDI data rather than audio, its not so important.

One of the main problems was getting the two big wheels to be of any use. I wanted to use them to rotate the hue around the spectrum for channel A on the left and channel B on the right. The original design Behringer was intended to be used as a DJ controller, however when looking at the output stream the wheels only output a high or low value of 0 or 127. This doesn’t really determine any absolute or relative positioning at all only directionality.

I had to use a timing trick in max to make these usable. By reading the current value and comparing the change you can determine the direction, which then starts a decreasing or increasing counter. By monitoring this state Max looks at the stream and after a 20ms if any break in input occurs its stops the counter, which is in turn mapped to the hue of the colour swatch. After playing with the rest detection threshold this gave a relatively natural input feel from the wheels. However the control is of little use in sequencing as the value isn’t absolute or repeatable by any means. In the latest version this isn’t a problem as the hue can be quickly reached using relative shuttling then snapshot at its selected value for automatic recall.

Ideally a more robust controller along with an additional fader wing would be an ideal console for running the system from an operator to allow for more creative and interactive performances of the lighting. Larger shows would allow this to be an option and is something of course I would prefer as stage lighting is certainly an art of the performance, sensitivity, design and skill equal to that of a musician. This system was never designed to be a replacement of that but a tool that allows a hybrid operation of the two, depending on the requirements of the show.

Using a separate auxiliary network we can broadcast to handheld devices or any wifi connected device. Alternatively, using low cost radio transmission there are a number of exciting possibilities for audience interaction, but this is out of the scope of its current needs. Again I hope to work on a production where there is potential for this. Coldplay did something similar and its was extremely successful.

The overheads for max are very little due to DMX data stream being quite lightweight. Currently a single max instance outputs the data stream, which is somewhat of a risk. Initially this was ran from a macbook pro, which in some ways was quite preferential as the system would continue to run if a power trip was to occur, and also maintain communication with the DMXUsb pro device. Once fixtures were reset it would pick up communication instantly as the connection to the interface is the most important to keep alive. Luckily using LED fixtures now power consumption is rarely a problem any more.

In terms of fixtures a couple of moving heads would be great to add some movement to the stage and create some shape in the air as everything is a little static at the moment. Im looking at some compact moving heads for some of the small/medium sized venues.

As its stands its still massively a work in progress. It has as many flaws as it does merits. It certainly has been the single most valuable learning tool both in designing a modular system and learning about max & lighting control. I recently had a play with D-Pro lighting controller and learnt a lot from it. As useful as it was to have a developed piece of software to quickly build a show it was frustrating to work with its limitations (where in max you can just dive in and change something). Its not very exciting without moving heads to add some dynamics, but its a step in the right direction for a DIY approach to light control. Currently i’m trying to simplify the system internally and also make it as quick as other software to create looks and scenes to build a show. Then try and make it a little more flexible for new fixtures to be added, rather than manually having to connect things up!

To date, touch wood, the software itself has never fallen over during a show. Other more practical faults inherent of smaller venues usually involve power draw from strobes & blinders causing the lighting circuit to trip (Usually at old venues). Luckily this is all downstream of the rack so it comes back online with a flick of a switch. Since we have moved to LED batons this is rarely an issue any more. I’ve also got distro for 32 & 16 amp supplies which is always plenty. I try and perform a soak test during the warmup act, running all the lights up for an extended period. If this proves problematic I usually reduce the overall master to demand less from the supply.


I get quite a few emails and comments asking if the software is available. At the moment the answer is currently no. As it’s still in its early stages I would be forever answering support questions from confused users. It’s not quite elegant enough and its probably a little messy. It’s designed to work with specific fixtures that I own as well as the hardware so it requires really getting your hands dirty to make it work for your specific needs. Hopefully its something I can share in the future when I get it to a more robust stage. However i’m happy to answer any questions you have or point you in the right direction if you come unstuck. Happy patching!


I used the DMX USP pro interface with a 5 pin to 3 pin neutrix jumper. Its integrated in max via the dmxusbpro external from Olaf Matthes. Well worth the €10.00 license.