Lighting programmers must put a high level of trust into their lighting consoles. Not only do we count on them to save our work and properly play it back, but we also tend to trust that the data being displayed is accurate and correct. However, this is not always the case; and every programmer should understand the possibilities and limitations of the wonderful consoles that we trust our livelihood to every day.
The Big Elephant
The number one biggest problem with incorrect data in lighting consoles comes from the big elephant in the room: fixture libraries. A fixture library (or profile) assigns console parameters and values to the DMX protocol that the fixture is “listening” to. I would love to say that all programmers understand that having a proper library for each fixture is essential, but we all know that this is not the case.
The very creation of fixture libraries leaves them ripe for errors. Generally the libraries are created simply from reading the DMX protocol provided in a fixture’s user manual. Furthermore, the naming of parameter types can vary immensely. For instance, I was recently programming a very popular LED ellipsoidal and the standard library had the colors defined as “Red, Green, Blue, Amber, and G1”. You might ask, “What color is G1?” I knew that the fixture had a lime emitter and thus quickly determined that the lime parameter was called G1 in this particular library. I don’t know the history as to why it was labeled as such, but another programmer could have easily looked at the profile and thought that their fixture only had Red, Green, Blue, and Amber LEDs. I took the time to correct the library and assigned the previous “G1” moniker to a parameter named “Lime”.
Another Example
A few years back, I was speaking with an LD who was complaining about a particular arc-sourced moving light looking a bit green on the actor’s skin. I asked if he had used the minus green color chip on the fixed color wheel. He said that he and his programmer had looked and that the fixture did not have a minus green. I referred him to the user manual that clearly stated that position three on the fixed color wheel is indeed a minus green chip. As it turns out, the fixture library in use had this position labeled as “pink.” In the midst of programming, both the LD and the programmer trusted their console’s library labeling and assumed that there was no minus green chip in their fixture.
It is essential that programmers take the time to understand the fixture libraries they have selected to program and compare them to the actual DMX protocol of each fixture. Only then can you fully understand and trust the data presented to you by the library.
Real World Values
Once upon a time, there was an automated lighting console that promised calibrated real world values within all its fixture libraries. This meant that the manufacturer was testing every single fixture and recording metrics for rotation speeds, strobe rates, color saturation, output intensity, and more. This dream of data calibration meant that you could assign all your fixtures to rotate their gobos clockwise at 3.6 RPM and they would all do the same and at that exact speed. Even with diverse manufacturers with wildly different DMX protocols, the console had the information to ensure all the values presented to the user would be uniform, consistent, and correct.
Unfortunately, the time and resources required to accurately measure all parameters of fixtures were nearly impossible. The development team had to abandon the calibration, yet they retained the real world value displays. Several other console manufacturers have also adopted real world value displays, although none are currently calibrating for reality.
This leads to a large problem where assigning gobos to rotate at 3.6 RPM will result in vastly different actual rotation speeds depending upon the fixture. Most DMX protocols do not provide the level of detail required for truly accurate real world values. For instance, the protocol may simply state that gobo rotation is from zero to 12 RPM as the DMX value for that channel changes from zero to 255. The actual rotation speeds at particular DMX values are not displayed and may or may not be completely linear with the DMX values.
A Real World Example
I heard an LD explain that he liked a particular desk because it provided him with the actual values for every parameter. He said that he would use this information to accurately determine the rate of strobe with different fixtures. He thought he could simply dial the strobe channel to a particular value such as “14Hz” and be assured that this is exactly what the fixture was doing. He was dismayed when two unique fixture types strobed different rates although both were set to 14Hz on the console. He actually said, “But the console says they are both at 14Hz.” I guess he should not have put so much trust in his console and libraries!
Non-Library Problems
Yes, I realize I have pontificated this entire article on the potential problems with fixture libraries. It is important that we all understand that they are not always true to what our fixtures are doing or are capable of creating. However, there are also other cases where the console may provide you with inaccurate or confusing information.
You may look at all the screens in front of you and determine that a fixture should be on at full intensity, only to realize that there is no light shining from it on stage. How could your console say it is at full when clearly it is not? There could be data problems, patch problems, or even a software bug that is showing the incorrect information. Furthermore, it could be that another process or parameter is overriding the output such as parking, shutters, colors, or even gobos. Maybe, just maybe, that dreaded grand master snuck its way down!
Programmers need to recognize the various ways in which data is displayed and learn to quickly troubleshoot to determine what is exactly happening on the stage. Remember that the console may not always display exactly what is correct.
The very worst lie that your console can tell you is that it has successfully saved your show file! It can happen even on the best of consoles, so it is always a good idea to make multiple saves to various types of media. Just last week, I was loading a show file from a USB stick only to learn that it had not saved correctly! Luckily I had other copies of it and was able to restore the file. However, the console did not report any errors when I had saved it originally.
Trust is Important
It is very important that every programmer trust that their console is going to present accurate data, behave as instructed, and report back on important processes. When you lose all trust in the machine that you work with every day, then it might be time to change to another console. Always check fixture libraries against the DMX protocol in the fixture’s manual before you begin programming. Make corrections to libraries as needed and be sure to report the updates to the console manufacturer. Remember, just because your console says so, does not make it true!
