Lighting programmers must have proficiency when it comes to preparing and maintaining the patch in their show file. Without a patch, there will be no communication with the connected lighting fixtures and other products. Although there is a promise of automation when patching, our industry currently fails to provide these tools in a reliable manner. Proper patching is an essential skill that every programmer needs to understand and utilize on all shows.
Principles of Patching
Every lighting fixture is assigned a DMX start address and universe where the data will be sent. Additionally, each fixture is given a user number that the programmer will use to select and program the fixture. With these two assignments, a communication path is created that allows the programmer to individually work with lighting fixtures.
At the heart of the console are fixture libraries. These define the attributes of a fixture type and the total number of DMX channels that each fixture will utilize. The beginning of a patching process starts with finding and selecting the correct library for your fixture. If a library does not exist in your desk, then you need to locate or create a library.
Many console manufacturers have a location on their site (or a specialized site) for distributing fixture libraries. Often, you can find what you need on these sites. Otherwise, you can request that one is made, but this can take a long time. Instead, you can download the fixture’s DMX protocol (map) and create your own library. While time-consuming, it is usually rather easy to accomplish on the desk or with a manufacturer-provided library writing tool.
After selecting the library, you simply tell the console how many of this fixture type you plan to use. Then you begin the patching process, assigning unique fixture numbers to each fixture in your show file. The next step is to define the DMX start address and universe for each fixture. This data can be created at the console at the time of patching or the LD or crew chief may have already assigned it. Either way, it is essential that the DMX start addresses match both at the console and at the fixtures.
A typical patch may look something like this:
Note that it is possible (and normal) to have many fixtures with the same exact DMX start address. This happens because they are on different DMX universes.
But Wait, There’s More…
While the basics of patching simply relate to fixture libraries, user number, and DMX start addresses, there are usually many more options within a patch window on a console. Common fields and attributes include location, notes, pan/tilt inverts, dimmer curves, and other settings. Additionally, there may be methods to connect to specific pieces of output hardware such as nodes, processors, or even media servers. Then there are options to choose how the data is sent: DMX, Art-Net, sACN, or other protocols are common choices that might be available.
Take the time to read the user manual of your console to learn all the options available within the patch window. You may be surprised to discover some very unique abilities that could prove useful for your show. For instance, perhaps there is an option to set a fixture as non-releasable (or always on). In this case, the fixture will never respond to commands to release/off any playbacks. This is very helpful for backstage lights, emergency lighting, house lights, smoke machines, and other items that you don’t want to accidently black out.
Output the Patch
Patch information is essential data that must be shared with the rest of the lighting crew to ensure the entire rig works as expected. Often, it is handy to export your patch data and provide it to others so they can set the fixtures accordingly. Most consoles allow exporting to PDF, excel, and other common formats. Plus, in a pinch, it can be handy to simply take a photo of the screen and text it to someone who needs the data.
If you do make changes to the patch during pre-production, be sure that everyone is aware of the changes, and that various connected systems are also updated. Visualizers, paperwork programs, light plots, and other documentation should always be consistent with the most current patch settings.
Promises of the Future
Patching of lighting fixtures, assigning settings at each fixture, and building cable distribution systems are very complex routines that happen regularly on each production. Our industry is very busy doing lots of work that should be more automatic in today’s tech-savvy world. RDM has been around for a long time and has allowed remote discovery and setting changes of fixtures on a DMX line. However, there have been many limitations that have hampered widespread adoption.
Luckily, there are some new processes arriving now that hold great promise for a much easier world of patching in the future. First, RDMnet has recently been ratified and it has many advantages over standard RDM. The new protocol works over Ethernet and provides two-way communication between fixtures and consoles. Some of the big advantages of the new RDMnet involve DMX gateways and Brokers.
A DMX gateway will convert the Ethernet signal to a standard DMX 5-pin universe, while a Broker facilitates communication allowing multiple controllers with minimum bandwidth. The Broker is especially exciting, as it will handle the discovery of units on the network and relieve consoles of this burden. With standard DMX, the discovery process was slow and tasking, causing many programmers to not use RDM.
With RDM and RDMnet, consoles are able to query the connected devices to learn what they are, their parameters, their address settings, and more. This means you should be able to simply connect your console to the rig and then the desk will automatically know what is connected and assign the correct fixture library. You will need to assign only user numbers fixtures to ensure that each fixture is in the location of the rig that you desire. All this magic depends mostly on the console to communicate with fixtures and assign data. It also relies on the fixtures being compatible with RDM and willing to listen. Once both are communicating, the patch process will become secondary. Very few consoles are currently using RDM fully, but hopefully with RDMnet we will begin to see more.
Another new process to aid in the patch is called GDTF (General Device Type Format). This system allows fixtures, consoles, visualizers, CAD systems, and other paperwork products to easily share the same information. In short, it provides a specific set of data to all these resources to easily share fixture library, fixture attributes, 3D images, and more. Once fully implemented, you will see your fixtures working the same regardless of console selection, visualizer, or CAD program. Of course, it does much more and you can read about it in a previous PLSN article here: plsn.me/GDTF
Get Patching
No matter your skill level as a programmer, you must understand the basics of patching on your console. Without proper patching, you will fail to get control of your fixtures. Take the time to learn all that your console allows in its patch screen, and be sure you understand the various protocols and options. Prepare for the future by reading up on RDMnet and GDTF. Don’t be scared to patch, but do take the task very seriously. Remember also that once your rig is patched and working, you should not have to revisit the patch until your next show.
