It’s no secret that one of my passions is thinking about how to design lighting control systems for the entertainment industry. In this post, I’m going to try and give you a condensed tour of everything you might need to know about large lighting control systems.
Understanding Control Data
Let’s start by rewinding the clock and head back a time before the invention of ‘intelligent’ lights.
Queen offers an excellent example of the ‘old school’ lighting designs of the era. You can see hundreds of individual lights hanging in grids, which are usually a type of light called a Parcan. There’s not much to a Parcan, in fact, its often described as a car headlamp in a baked bean can.
Each light is connected to a dimmer, which allows the operator to set the intensity (brightness) using their console. In the old days, each lamp would have a physical fader (linear potentiometer) on the lighting consoles for settings its intensity. The larger shows would have consoles with hundreds of faders. It’s essential to understand the control desk is not directly regulating the amount of amperage to individual lights but instead provides a control signal to a dimmer. It’s the dimmer which controls the amount of power to the lights. The modern control signal that consoles send is called Digital Multiplex (DMX512) and importantly, allows for controlling 512 lights with just one cable. A DMX cable is often referred to as a DMX Universe.
Moving Lights
When people started attaching servos and other goodies to lights getting them to move and change colours, the control manufacturers had to evolve their systems to handle this new complexity. These types of lights became known as ‘intelligent lights’ or ‘moving lights’ and these new capabilities were controlled directly by the console and either had internal dimmers or shutters to control the brightness of the light.
These new capabilities called for the creation of new user interface/interaction metaphors, which could help the operator control many more control channels at once. One of the more popular metaphors was inspired by early sequencers and synthesisers. Consoles like the DLD-6502 even go so far as to give a subtle nod to synthesisers with copying the shape of the wooden sides.
Manufacturers around the globe competed to create unique lights which led to some interesting (and often difficult to abstract & control) developments, such as conditional channels. Another development from the advent of moving lights was the ability to increase the resolution of DMX data through grouping channels together multiple 8-bit values to create higher resolution values. This is normally used to provide 16bit control but can also be used for 24 and 32bit values to be used if required. In general most control systems will only support 8bit and 16bit control channels.
The difficulty with higher resolution control channels is that there is no standard on how manufacturers have implemented how to decode the values. Some manufacturers have opted to use Most Significant Bit (MSB) while others have decided for Least Significant Bit (LSB), which only adds the complexity when calculating output values. And herein lies one of the biggest problems with DMX control, there is no standard among manufacturers!
Most light manufacturers have had little regard to the challenges of controlling the fixtures they create as they can pass on that complexity to the controller developers.
One way controller manufactures deal with the complexity is to have an extensive database of DMX controlled fixtures that details a lights control channel values, labels, conditions and other important data for accurately controlling the light.
Most databases provides the ability to describe the fixtures by common denominators which can make it impossible to represent the state of more exotic fixtures in any meaningful way using existing control metaphors.
Modern Systems
Fast forward to 2019 and the industry has many consoles that still offer the user interface metaphor found on the Wholehog II, with a few experimental control metaphors failing to gain mainstream traction with professional lighting programmers. My personal favourite such console is the original Jands Vista, which saw the adoption of the Desktop metaphor, which feature a click/pen oriented user interface, and a timeline editor not dissimilar to video/audio editing tools. The Vista is still available today but now incorporates many metaphors of their competitors in order to cater to operators preexisting knowledge and expectations of a lighting control system.
High Risk
From an operators perspective, lighting control is high-risk! If you’re the lighting operator for the Olympics opening ceremony, you have just one shot to get it right with billions of people watching. If the lighting console crashes, you better have bought a backup that can gracefully takeover!
Traditional High-Availability
A second lighting console will usually be deployed in order to provide high availability. The second runs in a “tracking” mode, which means it replicates the state of the master console. It’s ready for the operator to switch to in case the master console crashes or goes offline. This is the most basic form backup that lighting programmers / operators may use.
This resolves the potential issue of loosing control of a lighting rig in the event of a crash, but the spare device doesn’t add any additional capabilities or take on any responsibilities for processing output data.
All data is still computed only on the master controller thus this approach doesn’t provide a distributed compute capability required to scale the system. This means that the operator is limited to a fixed number of control channels based on the consoles local compute capability, which is a trade off that most manufacturers and users are happy to make. Most consoles can comfortably process 16 universes of DMX (16 * 512 = 8192 control channels) .
Distributed Control
For the larger shows, having just a single console simply isn’t enough compute power to calculate the control data in real-time. For this reason, some manufacturers now use high performance computing techniques to provide scalable control systems that can run the most demanding of shows.
The aim of my control system is to be able to control up to 1024 universes of DMX. That’s 524,288 control channels, recalculated 44 times a second in as close to real-time as possible. In order to make this happen, I want to use spare compute capacity available on the local area network to distribute the storage and computation of control data. This type of architecture is often referred to as Grid computing.
To do this, I’m utilising Apache Ignite to create a distributed data grid along with collocated computations to create a horizontally scalable data and compute grid.
Wrapping up
In an upcoming post, I’ll go into detail about Apache Ignite and how I’m using it within the Light Console.
Light Console Dev 