A New Kind of Software

Clifton Taylor Sep 24, 2010 5:44am

Last week I received a demo from Rob Halliday* of the latest version of his FocusTrack software system. FocusTrack is designed to make the process of documenting a show that uses moving lights —how they are focused, colored, and used within the show file—MUCH easier and more accurate than doing it by hand.

The software is an application that lives on a laptop and has the ability to read a show file from several popular consoles, read the Lightwright data file that corresponds with the same show to create a combined database of cues and purposes. Furthermore, the system is tricked out to be able to OPERATE the console as well as a digital camera so that it can place each light into each focus state that has been created for it and then take a digital photograph showing how the light is focused. Focus Track currently works with the EOS/ION, grandMA, and Palette consoles.

This is not a review however. Seeing the software in action has really excited me, but probably not for the reasons that the software was originally developed. I think that FocusTrack has the potential to form the basis for a new CLASS of tools that currently doesn't exist. By combining the Lightwright data for each light, with all the data that the console stores about states (cues), groups, color palettes etc, FocusTrack has the potential to become a kind of MIS (Management Information System) tool for lighting designers.

Up until now, the console manufacturers have struggled to provide an interface that is actually in the service of two masters. One is the programmer, whose work requires quick navigation, reduced keystrokes and a need to access a huge amount of data shown in often dizzying amounts of detail. The second is the designer, whose requirements are increasingly at odds with the programmer's. The designer actually usually needs summary information. If he/she has a competent programmer, he/she doesn't need to or want to read through screens full of information at the design table—better to keep all eyes on the stage.

Rather, the information that a designer needs from the console actually probably requires some additional processing to be able to present it in summary and report like fashion. Instead of seeing that channels 1-16 are at 75%, wouldn't it be better to see that the "High Sides" are at 75%, or that "group 1" is at 75%? Instead of seeing that fixture 1 is pointed at the focus point "window," fixture 2 is pointed at the "staircase,” fixture 3 is pointed at the "window," fixture 4 is pointed at the "staircase" and fixture 5 is pointed at the "painting," perhaps it would be more useful for the designer that the system could re-orient the data around purposes, showing us that there are lights focused at the window (1,3), staircase (2,4) and painting (5) as the primary display.

The designer with that kind of information could more easily and intuitively rationalize the focus data to know that he/she could use fixture 5 because the painting doesn't come up for two more scenes. Once a fully relational database of all the data that we use in lighting a show is combined into one system, all kinds of real-time analysis become possible.

For instance, as a designer, I think it would be useful to be able to see at any moment in the show what lights haven't been used. Or perhaps only used once or twice. Perhaps I'm low on dimmers and want to add a special but would have to combine other lights to do so. It would be useful for me to know if two or more lights have always been programmed at the same level throughout a cue stack. More complex analysis might cause the program to look at iris and focus data for a fixture throughout the show file, allowing the designer to see that different lensing might be more appropriate for that particular fixture.

In the 1990's, I developed a DOS program to (among other things) analyze channel usage across a show in an ASCII cue file (Trackmaster). Because it remains the only program that provides some of this functionality, I occasionally still use this tool today. More recently, Eric Cornwell developed a great program called Virtual Magic Sheet, which analyzes the DMX stream to reconstruct a live presentation of the state of the board output in a highly customizable screen display.

What I would like today though goes beyond the functionality that was available or needed in the past. With moving lights, LEDs, projection systems and DMX universes counted by the dozens, I have a real need for a designer's information system. I find that when I have a competent programmer, I don't actually want to see his or her keystrokes or screen layouts. What I really want is a customizable set of displays that tailor and summarize the board's information for me.

Rob Halliday's program, built on top of Filemaker Pro is the first system that I've seen which begins to fulfill this need. While he has built it for a very specific purpose that many of us reading this article will frankly never encounter (the need to document a large Broadway or West End show so that it can be moved across the Atlantic, to another theater in town, or go on to tour), I realized at his demo that the system has the potential to fulfill a much larger purpose for many more people.

Halliday's marriage of the Lightwright and the console data files creates a much more useful dataset, one that is much more valuable to me as a designer than each were as discreet systems. Imagine what is possible once these data are brought together in a relational system: The entire display of data could be re-oriented around purposes and systems and groups, making the display of lighting data more intuitive and much more useful than a screen full of numbers.

Cue data could be shown to me by system (ie, shins at 40%) instead of by channel numbers. Groups could be automatically generated based on purpose fields within Lightwright. Outside of displays, the system could be programmed to analyze channel usage across cues. This could be used to suggest optimal groups automatically, to show equipment that isn't used in the moment or during a range of cues. Lightwright data could instantly be reconciled against patch changes. I think that it is proper that this system not be a function of the console, but a separate system that interfaces with the console and other data that are important to the lighting of the show.

With our current separate systems, we ask for the manufacturers to provide new functions on their consoles to make our work easier / faster / better. Perhaps it is time to allow the console interface to be totally designed around the programmer's experience and the designer's information system to be totally designed around the needs of the designers. Each system could both pull information from the same common data source, but each could be made better by being purpose built for their end users.

So, what would this Designer's Information System look like? For me, it would be extensible and flexible, providing programmable screen layouts, persistent (savable) queries, and varying levels of data analysis tools. It would be great to have access to the memory structures in the console as well as the file structures so that we could see the current state onstage and other cues in blind, the cue list, and perhaps even the command line. Graphically, in addition to text based reports and displays, it would have the ability to incorporate the ideas pioneered by Virtual Magic Sheet, but also have a more robust and deeper access to the board data than is available only by looking at the DMX output.

For me, the ideal system would be console independent so that it was a product that I as a designer owned and carried with me. Plugging into the lighting data network, the system would be able to talk to a range of consoles to provide data to me in a consistent and personalized manner. Thinking further out, I would love it if the consoles would allow themselves to be partially set-up through the DIS system. That way, I could keep a palette of color values that might be personal to me without the tedious task of constantly re-entering this data into new show files.

Actually color is a subject that I could go on and on about but will refrain in the scope of this article. Perhaps it is sufficient to say that we are entering a very interesting period of software development in the lighting field. I think that Rob Halliday’s software is pointing the way.