The story of the first use of computerized control on broadway is well documented.   Tharon Musser created the lighting for "A Chorus Line" on Broadway in 1975 using a custom made lighting controller based on a PDP-8 Processor called the LS-8.    

Four years later, Strand Lighting introduced the Light Palette, a console which truly revolutionized American theatrical lighting practice on Broadway and eventually throughout the professional theater.   

   

Principally, what was revolutionary about the Palette was its programming interface.   It featured a visible command line that had a syntax that closely mirrored the natural language conversation between a designer and an electrician.   

This is almost exactly the same syntax that a designer would use to speak to an electrician operating a resistance board, and the use of this syntax in the lighting desk made it very simple and intuitive to operate.   Consequently the Strand Light Palette quickly became the standard console throughout the country.   

In addition, the Light Palette was a "Tracking" Console.   Before computers and before preset consoles, when stagehands manually operated a bank of resistance dimmers, "Tracking" was the standard practice.   This makes sense when you think about it.   Here is an example.   Let us say that you have a cue 1 recorded that has dimmers set at different levels for a night scene.   There is moonlight through a window, there is blue fill light, etc.   The second cue happens when an actor enters the scene and turns on a practical lamp.   The only thing that we want to have happen in cue 2 is the practical lamp turning on.   All the other dimmers should remain at their previous state, and "Track Through" into the current cue.    

the instructions to the electrician operating the resistance dimmers would record all the states of the dimmers for the 'moonlight' scene for Cue 1.

the instructions for Cue 2 would direct the electrician to add only the dimmer for the practical lamp to the scene.    

On a manual system, it would be confusing and redundant to restate all the levels of the 'moonlight' scene, because these levels weren't changing when the lamp is turned on.   

This is a natural and intuitive way to operate stage lights.     If for instance, later on, the designer wants to change the light that is coming in through the window in Cue 1, this change should naturally "Track" into the next cue as well.  With a preset console, the revised level in the window light would have to be updated in every subsequent cue until the scene change.    To me, this is counterintuitive.   

The Strand Light Palette successfully replicated this longstanding manual practice in software and consequently became the standard way to operate stage lights in the theater.    In fact, this interface became so ingrained and useful that it has been replicated, with varying degrees of success, by many subsequent console manufacturers.   It remains the standard on Broadway today, embedded in the ETC Obsession 2 console and the newly available EOS. 

This past week, I was invited to see a preview of the new grandMA 2 console at ACT's offices in New Jersey.   I can easily say that it is a very elegant control desk which further extends the state of the art in lighting control, and I look forward to being able to use it on a show soon.   It is a major upgrade to the nearly 10 year old grandMA lighting console.   It significantly expands the control capacity of the system with faster networking, increased channel capacity, more refined programmer interface and more robust command line syntax.      

I think that with both this desk and the new EOS console from ETC, we are *beginning* to see a kind of convergence of the previously separate interfaces of moving light consoles and theater conventional tracking consoles.      I should state here that I am NOT a programmer, but a lighting designer, and consequently my desires for a console are from a specific point of view, which naturally could and should differ from the point of view of a programmer.    I was very lucky at the grandMA demo to have two wonderful programmers with me, Paul Sonnleitner and Bobby Harrell.   Both Paul and Bobby have programmed on Broadway for me and Paul works with the grandMA folks on the designs of their consoles.   

After the demo, we got into a discussion about the desk and I said that I thought that there should be more work on the programmer interface, specifically to make the syntax more robust.    One problem that we have today in the theater is that if we use moving lights on a show, we need a highly trained programmer to put the show together.   In New York, even off-broadway, this is not a problem, as we are lucky to have so many very skilled and talented programmers freelancing.    However, in a regional theater or other venue outside of New York or LA, these folks are few and far between and often have to be flown in for the technical rehearsal period.     This fact, along with the cost of the moving lights themselves, has traditionally limited the adoption of intelligent light technology in theaters outside of the major markets.     Last season, when I lit "Treasure Island" at Houston's Alley Theater, I was very lucky that a local, and very talented 'Hog' programmer was available.   Otherwise, we would have had to bring in someone from out of town.    The Alley is one of the premiere theaters in the US and would have been able to bare this expense, but when I worked at Cincinnati Playhouse in the Park previously and was asked by the director to incorporate moving lights into the production, we all had to suffer through trying to program the moving lights on a theater console with no moving light support.   That was not an optimal situation.

The brilliant thing about the command line interface that was started by Strand's Light Palette and is currently expressed in the interface of the Obsession is that generally the programmer has only to type what the designer says.   It can happen as fast as the designer says it.    In its attempt to recreate a natural language conversation, the interface is elegant and easy to grasp.   

What I wish would happen in the next generation of consoles is a deep and rich expansion of this idea.   If I have moving lights on a show currently, I can say to the skilled programmer, "make fixtures 1 and 3's gobos rotate slower."    Very quickly, the programmer has to know, or be able to figure out, which gobos are currently selected and rotating for fixtures 1 and 3.   He has to know which direction the specific gobos are currently rotating and he further has to know what kind of fixtures 1 and 3 are because the interface for slowing down a rotating gobo differs greatly depending who made the fixture and, in some cases, even the specific model must be known and understood because the way a gobo rotates can be different between models of the same manufacturer.   That is alot to figure out or know, and it has to happen very quickly because the designer and the director want to move on.   

All of this, the computer could 'know'.   In fact, this kind of 'figuring out' is something that computers generally do VERY well.     From a programming standpoint, it is like a query into a database that joins the data of the current state of the lighting with the data of the operating specifics of the luminaires with the command line directive.    

I propose that the computer should figure out which gobos are rotating in fixtures 1 and 3 on its own, it should be able to determine the method for slowing down that rotation regardless of their direction, and it should be able to execute that command from a directive as simple as:

Now this is just one example, but I'm suggesting that every function of every type of light be virtualized in this manner.   As a designer, I shouldn't have to care that gobo rotation is parameter 13 on moving light x.   Today, I can either get the producers to hire a very skilled programmer who does know these specifics and can keep up with me saying "Slow down the gobos in fixtures 1 and 3", or I can learn that it is in parameter 13 myself and walk a less-skilled programmer through the steps to slow down the gobos.    

I believe that if a console had a command syntax that was this robust, moving lights would suddenly become available tools to every theater because an console operator could (again, as on conventional consoles) reliably type into the console what the designer naturally says.    Of course, I'm not suggesting that this high level interface REPLACE a more specific and exact lower level command interface, nor should it replace a graphically oriented user interface.   Rather I think that the three interfaces should ALL be available to the programmer simultaneously.   This way, a designer or programmer could approach the desk at his or her own skill level.    This kind of interface would harness the long-standing and deeply-embedded designer and stage-hand skill set for programming conventional tracking lighting consoles, while naturally extending these skills to a world of intelligent lighting.   

I must say that I also don't believe that having this kind of high level interface would put skilled programmers out of business.    I think its well established on Broadway that the programmer is much more than the person who figures out that parameter 13 has to move closer to 50% to slow down the gobos.   On the shows that I have been lucky enough to work with very talented programmers, they have added tremendously to the overall creation and polish of the lighting and were in every case invaluable collaborators in the final product.    I do think that this kind of robustness would speed up the work in the theater, and would free both the designer and the programmer to work on creative issues and solve deeper problems.   

Now of course both the EOS and the grandMA are attempts at this very thing.   And in fact, this whole article might exasperate the creators of these desks because it is precisely what they are attempting to do (along with many other incredible and wonderful improvements) with their latest releases.   But I can say that neither console has embedded in their command line syntax this level of programming.   Yet.    

But hopefully, this is where the consoles will be soon.

Comments?