Once upon a time not so long ago, every lighting fixture needed just one control channel. Very soon, it could be that every fixture needs one entire DMX-512 universe. Is your control console ready for that?
CONTROL OF THE PAST
There was a major upheaval in lighting control 20 years ago when the first moving lights appeared. Up to that point, lighting control consoles had only to deal with a single fading channel for every fixture: its dimmer. Large numbers of dimmers to be sure, but only one per fixture, and that one control channel was pretty much always one where higher levels were more important than lower levels (brighter always wins over dimmer), and thus simple ‘Highest Takes Precedence’ or HTP logic could prevail.
In the 1980s, apart from the occasional color scroller or semaphore changer, control consoles were pretty much dealing with this single-channel HTP control. Consoles had relatively simple programmer sections to access and set these channels but had increasingly sophisticated playback areas to allow very complex output control with multiple, overlapping moves all happening at different times. Then, along came moving lights, and suddenly, HTP didn't work anymore. It is clear that “bright” takes precedence over “dim,” but why should “right” be any more important than “left” or “Gobo 3” take precedence over “Gobo 1”?
What was needed was a look back to the 1930s and the LTP (Latest Takes Precedence) logic prevalent in those mechanical dimmer racks and controllers. In addition, that logic had to apply all the way through the console, from programming to playback. You also needed a more sophisticated programmer section on the console to deal with the multiple simultaneous channels that a moving light needs, maybe up to 30 or 40, rather than just one dimmer level. It took a while for moving lights to become common, and a number of proprietary consoles dedicated to specific moving lights came and went before generic moving light consoles came along. A number of successful generic consoles, such as the ubiquitous Flying Pig Systems Wholehog® 2, embodied the features we have just mentioned — fully LTP and a programmer section capable of handling all those parameters in a way that allowed the operator to understand what was going on.
CONTROL TODAY
So, that's where we sat in 2002 — two types of consoles (slowly converging), offering every type of control you could possibly need. Then along came LEDs and media servers to mess it all up again.
Let's look at LEDs first. The industry has developed two types of control consoles: conventional lighting consoles that can handle thousands of channels of HTP dimmers and moving light consoles that handle large numbers of fixtures, where each fixture has tens of parameters. However, with LED fixtures, you have potentially thousands of fixtures where each fixture has three or four control channels, and that control is a mixture of HTP and LTP (HTP for brightness and LTP for color). Frankly, neither console does a really good job of controlling these. It is cumbersome and tedious to program very large numbers of small fixtures. One solution has been to map LEDs to the pixels of a video signal, which brings us neatly to media servers.
With media servers, 30 or 40 channels per fixture aren't enough anymore. A media server can easily require hundreds of channels simultaneously. Consider a modest sized lighting rig of 100 digital lights with integrated media servers, and you could be looking at 30,000 control channels or more! Suddenly, DMX-512 isn't looking like such a good idea. Those channels aren't all LTP either. Some are parameters such as brightness and transparency, which you could readily argue could be dealt with as HTP. Although there are ways to work around the huge increase in channels (such as splitting a media server up into its component layers and treating these as separate logical fixtures), these are not good long-term solutions. In many respects, we are back in 1985 looking at a moving light and our three-preset manual console wondering how on earth we are going to make it all work.
COMPLICATION: CUSTOM CONTENT
In addition to the obvious physical problems of controlling something like a High End Systems Catalyst™, Martin Maxedia, or Green Hippo's Hippotizer from a normal lighting console and paging through hundreds of control channels, there is the additional concern of being able to see what you are doing. A lighting designer, when faced with a new moving light, might ask the console operator to “show me all the gobos, and let's see what we've got.” Try that technique with a fully loaded media server, and you'll be there for many hours, if not days. That approach simply doesn't work any more.
Even before he starts, a designer will need a very good idea of the looks he wants and the content available when using a media server. In fact, he is likely to spend some time working with a graphic artist creating content of his own. Designers have always created custom gobos, and this takes that process to a much higher level. Even more importantly, once the content is in place, the designer will need a control surface that allows much easier access to that content in a very visual way. Working with names and numbers is going to be too slow and inappropriate for this highly visual medium. A whole new highly visual language and interface needs to be developed to match.
As an aside, the Jands Vista is an interesting development. Although designed for moving lights, the visual interface with its multiple overlapping timelines may turn out to be appropriate for controlling multiple banks of LEDs or media servers. The look and feel of this console is very different from what we have become used to in the last 10 years. The learning curve is thus quite steep, but thankfully, relatively short, and the very visual interface may lend itself to working with visual media.
COMPLICATION: DEVELOPING TECHNOLOGY
The scariest (and perversely, the most exciting) part is that we have just started to scratch the surface. The introduction of integrated products such as the long awaited High End Systems DL.2, where the media server is part of the lighting fixture, brings with it an exciting level of creative opportunity but also an escalation of concerns about control and media content management. Now, we do not just have one or two media servers next to the lighting console where you can reach across and load new content. Instead, we have perhaps 50 of these in the rig where we have no access at all without climbing the truss or getting out the Genie lift. How do you get new content into the servers? How do you make sure they've all got the right content? And, just as importantly, how do you make sure copyrighted content is removed successfully when the show is over?
If you look at the biggest uses of media servers to date — The 77th Annual Academy Awards and The Eurovision Song Contest come to mind — the results can be absolutely stunning. However, in both those cases, there was a backroom infrastructure to make sure that the media servers were installed properly and kept happily fed with fresh new content. In the other 99.9% of the shows we work on every day, that isn't possible, but the producers and our clients will expect similar results — and rightly so. We are an early-adopting industry, and this is what we do.
SOLUTION: NETWORKING
It seems clear that networking of some kind is going to play a bigger and bigger part in our everyday lighting lives. In fact, it is impossible to consider that this kind of product is even possible without a high-speed network backbone to tie it all together. We all must make sure we know about networks, cabling, hubs, and switches, fiber and twisted-pair, and everything that goes along with it, because very, very soon, we are going to be rigging it on every pipe and every truss to every fixture. The electrician on a road crew will need skills more akin to an IT tech in a large server room with large banks of computers to boot and connect every day. But it will be more difficult than a computer server room. How many server rooms do you know get packed in road cases and trucked to a new location every night?
What we are looking at here is a whole new breed of control, perhaps add-on wings to existing consoles or something more ambitious. You can see the seeds of this in the product pairs that exist today: Martin's Maxxyz and Maxedia, Flying Pig Systems' Wholehog® 3 and Catalyst, PRG's Virtuoso™ and EX1, and the connection between Chamsys and Green Hippo, where the console has access to the Hippotizer server to show thumbnail previews as a selection aid. The latest release of software for MA Lighting's grandMA also has the ability to talk directly to a limited number (15) of the company's grandMA video media servers and show preview thumbnails on the console screen. A new console needs a lot more than this to be effective at controlling integrated digital lighting. You'll need to be controlling large numbers remote media servers and will expect the same kind of grouping and mastering controls that you have today with moving lights; you'll need to be able to select the content you need from hundreds or thousands of images and clips in a slightly less painful manner than reviewing them one by one; and you'll demand comprehensive feedback on what's going on inside the server. When your final “gobo” image is made up of eight other images overlaid, skewed, distorted, blurred, and entangled, it is difficult to figure out what knob to turn for the desired end result. Anyone who has spent time programming media servers from current consoles will know precisely what I mean. The end result is fantastic, but the creative process can be very painful.
Digital media content also introduces another level of timing that designers haven't had to think about before. Not only do designers work with familiar timing such as, “I want that spot to move from point A to point B in five seconds with color change delayed one second, and the gobo changing as a snap at the end of the move,” but superimposed on top of that is the timing of a movie clip that's taken the place of that gobo. This brings up new questions: When do I want the clip to start playing? How quickly should it play? When should it end? How on earth do I decide and then check what I've decided is best?
Looking at the current situation, moving light consoles, in general, embody different playback methods and controls than conventional control consoles. Each type of console has its distinct and specific modes of operation, and programmers have their own preferences and familiarities based on their experience. So, although the moving light console is probably capable of running the conventional channels (and vice versa), it is often more convenient for shows with large rigs of both conventional dimmers and moving lights to use two consoles, one for dimmers and one for moving lights. One wonders if the same thing will happen with media servers. Will we see a second (or even third) console dedicated to media server control?
I have the luxury, as an author, that I have no obligation to present solutions. I can just present the problems as I see them and gaze into my crystal ball hoping and believing that someone somewhere will design the answer. My concern right now is that the problem is not being seen quickly enough. It seems like it is no big deal to struggle with two Catalysts for a few hours. But it will hit us like a stage weight falling from the grid within the next two years. We will have products that we want to use, and we will have the imagination to see how we want to use them, but we won't have the tools to allow us to link the two together.
I have my own ideas about what that solution will look like, and I'm sure you do too. Whatever it finally turns out to be has the potential to be as big a jump from today's moving light controllers as the Wholehog 2 was from that three-preset manual console.
All About HTP
HTP (Highest Takes Precedence) hasn't always been easy to provide. If we go back a bit further and look at the motorized and mechanical control consoles of the early to mid-20th century, it was often only possible to implement a “Latest Takes Precedence” (or LTP) scheme when the last physical movement of a motorized transformer or clutched dimmer was always the most important. At that time, the function of cross fading (usually move fades rather than cross fades, in fact) happened in the dimmer, not really in the console. In fact, the dimmer and console were often one and the same physical piece of equipment. It was the introduction of dimmers that could be controlled to any level via a simple control signal and the subsequent moving of the fade functionality from the dimmer to the control console that made HTP a reality. With the introduction of analog electronics, HTP was also very easy to provide. If your control signals are DC voltage levels, then just connecting two control lines together using diodes gives you HTP. The introduction of digital electronics in the 1960s and 1970s gave a choice again between HTP and LTP, but by that time, HTP was deeply engrained in users' minds as the right way to control dimmers. The conventional light tracking consoles introduced at the time used a mixture of HTP and LTP. Only level changes were recorded in an LTP manner, but the final output logic was often still fundamentally HTP, with multiple masters being overlaid in a standard HTP manner.