Skip to content

Peeling Back the Layers

Share this Post:

Each year it seems that new lighting fixtures become more and more complex.  If you attend any lighting tradeshows you will find that most manufacturers have LED fixtures, media servers and digital lighting products.  These unique products are very different in output and control from good old “automated” lighting fixtures.  Many of these units require knowledge of their protocol as well as a good understanding of how they interact with a lighting desk.

 

Unfortunately the consoles of our industry have not yet fully embraced the capabilities and requirements of these newest products.  For this reason, it is imperative for automated lighting programmers to be aware of the complexities and requirements of the newest offerings from lighting manufacturers.

Automated lighting consoles are great for programming “conventional automated lights” that have a single set of parameters.  But when a fixture contains many layers or cells of the same information, most consoles have trouble.  

For example, imagine a simple LED fixture that has three cells, each of which have red, green and blue parameters.  An automated lighting console has trouble with a fixture like this because it expects a fixture to have only one color system, not three.  A fixture of this type does not fit into the color picker, fanning, spreads, copy functions and other console features that are designed to work between fixture types, but not within a single fixture.  So to get around this, users will patch three identical fixtures into their console to control one real world instrument.

In order to program this instrument the programmer must select three unique fixtures on the console, each controlling only a part of the instrument.  The downside is that you must remember which fixture numbers relate to which portion of a fixture and some features such as Highlight or ID may not function.  The plus to this method is that effects, fanning, copying and more are much easier across multiple “fixtures” than within a single “fixture.”

The problem can become even more complex with media servers and digital lights.  Most of these units use multiple layers that contain many of the same parameters on each layer.  For instance, if you are programming a digital fixture you might have one motion layer, one global layer and three graphic layers, all of which control the same instrument.  To the lighting console these will be setup as individual fixtures, each with their own unique fixture number.

Again the benefits of this method far outweigh the disadvantages of having all parameters on one single fixture within the console.  In the example above, imagine that each of the graphic layers contains 40 unique parameters.  This means that if you were to select the fixture as a single unit, you would have well over 120 attributes to adjust at once.  Never mind the fact that many of them repeat in name as they are applied to each layer.  That is a lot of data to have to keep track of on the screen and with the encoder wheels on your desk!  I would much rather select each layer one at a time and work with “only” 40 parameters at a time.

When you’re working with multi-cell LED fixtures or digital lighting, it is essential that you number your fixtures in a method that helps you to quickly recall the various portions of each instrument.  When I work with digital lights for example, I will number them using a three-digit system where each digit helps me to remember the purpose of that fixture selection.  So again using the above digital light example, I would number the fixture as follows: 121 – motion, 122 – global, 123 – graphic 1, 124 – graphic 2 and 125 – graphic 3.

I can instantly remember and locate each portion because I know that fixtures in the one hundred range are digital lights (the first digit).  The second digit tells me the “instrument” number; the example given is for digital fixture number two.  Then the third digit defines which portion of the instrument I am working with: 1 – motion, 2 – global, and so on.

Now I am sure you can quickly see that if I select fixture 163 on my console that I have selected graphic layer one on the sixth digital light.

When I am working with more than nine digital fixtures then I will apply the same technique but start my numbering in the thousands instead of hundreds.  As I stated before, this same principle can be applied to LED batten type fixtures.  Many of these units must be patched as a number of cells that correspond to the different sections within a single instrument.

When you’re working with multi-part fixtures, you must remember the structure when patching.  If you are working with the above mentioned digital light, you must patch each portion in the correct order that matches the DMX protocol, while ensuring the sequence starts at the DMX start address for the fixture.  So in the example, you would patch the motion layer first at the DMX start address, then each of the other layers in the order that matches the protocol at each successive DMX address.

If the layers are patched out of order, then the fixture will not respond correctly.  Furthermore, care must be taken when patching multiple instruments to ensure that all the parts of each instrument are patched before the next instrument is patched.  You cannot start another fixture at an address that overlaps part of an existing address.

In the future automated lighting console manufacturers need to confront the problem of multi-part fixtures with new console paradigms.  Programmers now require methods to quickly select fixture “parts,” yet also have the ability to copy and fan within and between each part.  New color tools should allow for quicker access to fixtures with multiple identical color parameters and better layer tools should assist with programming routines.  Other new concepts will ease the patching by allowing each instrument to be patched and addressed as a single unit.  When will these features be seen in modern consoles?  Soon, I suspect, as our industry keeps creating more and more LED fixtures, media servers, and digital lights.  Until then, it is imperative that programmers familiarize themselves with the current methods for working with these instruments and become proficient at the routines mentioned above.