Control Desks continued: Displays
Earlier this week I wrote a little bit about the new GrandMA2 console and the command line interface. There was a long bit of history in that post, but I put that there to remind us all of how we got to the place we are today with lighting consoles. One thing that I've learned from years of working in Europe and Asia and South America is that the way we work in the US Theater is unique in the world. Perhaps less so today than 10 or 20 years ago, but we still have some unique working methods. For making theater lighting in a well-off country, I think the US system has some great advantages both for the designer and the production, but the fact is that we do many things differently in the US than in other places.
One of the biggest differences that I've found is the separation into different positions that we have come to expect between the Lighting Designer and the Programmer and/or Operator. In many places, these various functions are performed by one person who stays with a show over its entire life. I'm not saying this is always the case, and certainly, in many places in the american theater, there are plenty of designers who operate their own consoles, but in general, in the US professional theater, these are separate functions performed by several people. This separation of function has created the need for our lighting consoles to deliver remote display function to the designer. Before the ubiquity of the networked systems that we have today, remote video was delivered to the design table via a video cable. The screens on the designer's desk showed us exactly what the programmer of the console saw on his monitors. And with the simpler desks (only conventional dimmers, maybe some scrollers) this was fine. With the command line displayed, the designer could help the programmer create exactly the cue that he or she wanted. The programmer remained in complete control of every function of the console and could remain responsible for every aspect of the desk.
The introduction of automated luminaires, borrowed from the concert world, created a sort of crisis in for theater lighting designers and electricians, which is only now beginning to be resolved: they couldn't easily be programmed on the desks that had been built for the theater. For more than 20 years, the solution on broadway has been to bring lighting desks that were actually built for the concert world into the theater to program and operate the moving separately from the conventional lights. The advantage of this system is that along with the desk, we can justify to a producer that is necessary to bring in a specially trained programmer to deal with the automated lights. With 2 desks and 2 programmers (conventional and moving lights), technical rehearsals can be more efficient. Also, because of the extensive training that the moving light programmer has necessarily received, he or she can be a creative asset to the lighting designer, offering solutions and ideas to the designer at a high level. So on Broadway, the standard for many years has been a Hog II console for the moving lights and an Obsession console for the conventional lighting. The two consoles would be linked by a MIDI connection, and the Obsession GO button would trigger the GO on the Hog cue stack.
With the concert systems, the programming interface has traditionally been graphical. Utilizing touch screens and operating in a non-linear manner, they do not lend themselves to providing remote display monitors like we are used to from the conventional desks. On the broadway musical "Hot Feet" that I designed a couple of years ago, I had a monitor from the moving light console showing me its cue list, but nothing more. I could see what cue the moving light console was outputting to the stage, but not much more. In fact, I was completely dependent on the (thankfully extremely talented) programmer to execute programming decisions properly. In a way, this was a great thing. I could concentrate on THE STAGE, and let go of needing to see a monitor. But it was a luxury afforded on Broadway and rarely in regional theater or off-broadway. When you can afford it, this system works. It is efficient and there is an entire community of designers, assistants, programmers, electricians, shops and producers on broaday who have become comfortable and familiar with this configuration of hardware and personnel. However, there are many situations in the world today where one wants or needs moving lights where the economics of the particular production do not allow for this elaborate set-up or the personnel to create, program, maintain and operate it.
And in these places - outside of Broadway - designers today can often get some moving lights into their plots, but cannot afford the separate console or the highly trained and specialized programmer. In these cases, we find ourselves in the position of NEEDING to direct and monitor the operator/programmer in the function of all the lights, including the automated ones. For this reason, I have long favored consoles that can operate the moving lights via a command line that I can monitor. This was the idea behind my earlier post, and it is why I prefer systems like the GrandMA2, the EOS and the Strand 500 series. It is a practical desire, so that as a designer not sitting with the console, I can help the programmer create the looks that I want.
Now, this is a post about monitors, and I'll get back to that, but there is one more bit of history and background that needs to be covered: Networking. As personal computer technology has progressed, we have become used to operating in a networked environment with our laptops in our offices. Network capable lighting desks have been around for quite a while now and the networking model offers many potential advantages: first and foremost is multi-tasking. In a networked environment, an electrician can be working on a focus with an assistant or fixing a lamp and bring up channels independent of the main desk. This way, a maintenance issue doesn't have to stop a programming session. To implement this, lighting desk manufacturers have generally adopted a 'multi-user' model, allowing each user access to the common DMX output stream while separating the command lines that create this common stream into separate environments. On the face of it, this is an elegant solution from an system designer's point of view because of its symmetry. Every person in the theater who needs a monitor from the lighting console is a separate (and equally capable) user with his or her own processor, preferences, monitor screens, and command capability. In such a system, adding additional users is as easy as adding an additional PC running specialized 'virtual console' software to the network. Both the network infrastructure and computer hardware are standard issue and relatively inexpensive.
But this model has some problems. In the theater, we don't easily fit into this symmetric model. Here is a schematic drawing showing a typical user set-up with a pre-networked conventional desk in a theater:
before networking, the designer's monitors (9 and 10) and the stage manager's monitor (11) were direct copies of the primary control desk's monitor 1 and 2. Everything that happened on the control desk's monitors was seen by the designer.
Most installations though nowadays, including temporary rental installations such as exist on Broadway, are networked. With consoles that can handle moving lights, there are many more monitors available to the desk, including some with touch-screen interfaces. Text has gone the way of DOS and all monitors now display information graphically, giving the programmer and designer potentially much more information in the same screen real-estate. A modern typical setup for a show might look something like this, with all the positions connected within a local network:
Each of the processors can potentially be in command of the system. Each user has preference control over their own screen layouts. But in the theater, most times, we don't want to give every user the same command capability. Furthermore, the users shouldn't be entirely separate. Each person has unique needs from the lighting control system.
Let's concentrate for a moment on the bottom part of the drawing, the Primary control desk and the designer's desk. The primary desk in this example has 4 video monitors, and the designer's desk has 2 monitors. As a designer, I actually DON'T want to know everything that a programmer/operator can know from his console. I want to spend most of my time looking at the Stage, not processing information on a monitor. Primarily, I would like a CUE LIST and a secondary screen that MOST of the time would display the INTENSITY LEVELS of lights.
With a network setup such as I've drawn, I am, as the designer, actually seeing information from a SEPARATE computer on the network. And because of the way that most console software is currently written, I can either be a separate USER, with complete control over the screen layout and my own command line *OR* I can be set up to be a mirror of the primary console. If I set up my desk to be a mirror to the primary console, I can see the command line of the primary desk (a really good thing), however, the screen layout may not otherwise be to my liking, because with still only 2 monitors, I would have to choose which of the primary desk's monitors to mirror.
What I actually want as a designer is for the modern console to at MOST times, replicate the RESULT of the pre-networked computers. I want to have one monitor show me a cue list, showing the active cue, the cue that is in blind or in the 'programmer' section of the console, and the times of the cue. On the other monitor I want to see the PRIMARY CONTROL DESK's command line. In addition, most of the time, as a default, I want to see a layout of intensity channels on the second monitor. I want the operator of the primary desk to have PAGING control over this display (like we are used to in a pre-networked desk, like on an Obsession console). But I also want to have the ability to Page the screen myself at the design table so that I can look at a cue's total intensities while not bothering the operator. I want both ways of paging simultaneously. I specifically do not want my own command line or control over the system, however, it would be useful if, in addition to local paging, I (or more usually, my assistant, could look at cues in blind independent of the primary control desk. To add one more twist to it, I want the programmer on the primary console to be able to show me other things from his console at times. Perhaps its all the attributes for a moving light, or all the timing information for a specific complex cue. But most important, the operator should be able to return me to the default setup with one or at most two easy keypresses whenever I ask, over-riding anything else I might have been doing with my monitors.
This is admittedly a strange setup if one thinks in terms of symmetric users on a network. It is in fact a sort of Hybrid User that has a few functions that are locally controlled, but also can see the command line of another user.
At the top of the drawing, in the backstage area, is still the stage manager desk. This should be like the designer setup in that its another hybrid. I want this user to have a cue list most of the time. But even here, the operator of the primary console should be able to temporarily cause this monitor to display other information from the console. Many times, cue notes happen backstage before the show begins and it would be useful if this display could show a designer standing at the stage manager's desk channel levels or moving light information. Again, though, it should be easy for the operator of the primary control desk to return this monitor back into a cue list with one or two key presses.
.....
I am the lighting director for a large dance festival here in New York and in Orange County California (Fall for Dance). The New York festival hosts 30 dance companies in 6 unique shows and we are in a constant state of tech with guest designers and company lighting directors coming through for their few at the design table to light their piece within our plot. Over the years, we have developed a rep plot that incorporates a lot of moving lights and scrollers to make the system as flexible as possible. Most dance companies don't yet use moving lights in their own plots and most of the time, I want to mask the complexity of the system for the visiting designers so that they can concentrate on the already difficult task of replicating their company's cues in our rep plot. The moving lights that we have are mostly used for re-focusable specials or to create a system (ie backlight or pipe end sides) that doesn't already exist in our rep plot. The visiting designer doesn't need to be involved in the nitty gritty of the moving light setup and in fact on their displays, I would prefer if they only ever saw intensity information, the cue list and the primary desk's command line. This is not possible with the current console's such as the GrandMA or the EOS.
Now I know that this is a somewhat unique situation. However, I am only asking that the new technology that we have replicate the abilities of the old technology. All of us who have been around long enough in the theater have been looking at the Palette/Obsession layout for nearly 30 years. Why not re-create it with a modern console? Of course, extend it in ways described above and in a million other ways that concert designers, television lighting directors, architectural designers and non-US based designers want, but don't throw away how we have been working for such a long time.
Last year, we had an EOS console for the festival with various monitors on the desk. Because time is so short, most guest designers couldn't begin to learn the particulars of the EOS screen layout in a useful way during their session. Many designers ended up ignoring the console screens altogether because of the difficulty of parsing the information displayed and the inability to have the operator control paging. If the EOS had been able to do what I am asking, the work would have been much more efficient. This is not just an EOS problem though. The GrandMA or the Light Palette from Strand would not have solved this in an any more useful way.
Its not enough to say that every user is separate and can see the data in any way that they want. There are specific needs based on historical precedent, union regulations, and styles of working that make the setup of these displays more complex and ASSYMETRIC.
If you got this far, congratulations! Thanks for wading through it! I would appreciate your thoughts and comments.
Nice thoughts Clifton.
One idea could be a "screen patch"
At the beginning of tech, the designer and electrician would set up designer monitors via a visual screen patch on the main console. Once the designer locked in the look, then this could be stored for future use. The next time the designer is in, their view could be uploaded as a preference.
Reply to this
Hi Clifton,
Fascinating to find somewhere discussing all of this stuff both publicly and, more importantly, intelligently.
I agree with much of what you say, but would note that much of it was available when using Strand's xConnect 'remote console viewer' dongle to connect a laptop to one of their late, lamented 500-series consoles. The dongle would allow you to set up multiple connections/displays at one time, each either being a mirror of what the operator was seeing (wht command line) or an independent display (with personal command line) with ('login') or without ('monitor') the designer able to interact with the console throught the command line.
Not quite what you're after, but with careful arrangement of windows on a monitor (perhaps stacking the operator's window under the designer's window so the command line was always visible).
Plus a character based display that was both familiar and incredibly easy to read, even at a distance. I, too, wonder why more modern consoles don't just copy the display formats of their predecessors.
Off to read more of your thoughts now.....
Rob.
Reply to this
Thanks for your comment Rob. I love many things about the 500 series and have used the console on many shows, including on Broadway last season, and think the programming of that console was a positive step in command line development. However, using more than a dozen moving lights on that desk always seemed problematic to me, as the interface became unwieldy above a certain scale. Also I feel it was unusable in a concert situation (I know, it wasn't built for that, but at this point in our development, couldn't we have a console that is versatile enough for many markets?).
I agree completely with your comment about text display formats. The consoles should be nimble enough to output many different formats, including text.
I'm planning to write about Eric Cornwell's (Westside Systems) Virtual Magic Sheet in a future post, but I'll say here that I think it is a wonderful program and wish that the console manufacturers could incorporate it directly into their products. The ability to lay out the display as one wishes, and the very well thought out graphical display of level and focus information are great reasons for everyone to have a look at this program. But I also love that the program acts as a web server, outputting its data to anyone on the network with a web browser on their laptop. This is such a powerful and empowering use of existing technology.
I think it would be great if the lighting desk could output elements of the display as separate html streams to the network. ie, a command line monitor, an intensity display, the contents of the 'programmer', patch information, and the stage output to start. That way, all the remote displays could be handled by everyone's own laptop without additional hardware or software. Each person in the theater could look at the data that was needed, without having to touch the console. And without having a dongle or other proprietary software loaded onto their machines. It solves the union issues of conflicting control, as the HTML output could be set-up to only act as a display technology, not necessarily an active command path (though that is the direction that the GrandMA2 is possibly moving in, see below).
Of course, this doesn't solve 'paging', but at least we are all used to moving around in a web page. And we are used to operating our own laptops. A clever html programmer could easily combine the desired elements, including a third party stream like virtual magic sheet or a visualizer such as wysiwyg into a combined webpage. Would be useful, yes?
Reply to this
Sorry for being very late to the game here, but I just wanted to let you know that I believe the GrandMA will provide whatever monitoring situation you desire based on your above comments. Designers can have their own monitor layouts or they can just see duplicates of what the programmer is looking at...your choice!
Reply to this