In most situations, copying is a bad idea. I have taught my son that copying from someone else’s paper in school or copying data for a book report from a web page is wrong. If I were to copy a previous article and submit it as a new one, PLSN would almost certainly reject it. However, when programming automated lighting, copying is a very powerful tool. There are many instances during programming where copying data speeds programming, provides quick references, and generally enables work to get done faster. As always, you should read the user manual for your console of choice to determine the exact keystrokes required to copy various types of data. Most consoles contain very strong copying syntax that can aid you during your next programming session.
Cue Copying
Probably the most commonly used copy function on a lighting console is copying one cue to another. As we often work with musically-based cueing, many elements tend to repeat themselves. For instance, a typical song will repeat verses and choruses. If the musicians are allowed to repeat the same music and words, then we should be allowed to reuse the same lighting cues as well. When building cues for a song, it is easy to copy the first verse cue after the chorus and rename it as the second verse. However, some important understanding of the cuelist data structure is required. When working with a tracking console, you will want to copy the “state” of the first cue into the subsequent cue. If you don’t, then you might end up tracking unexpected data into your copied cue.
For example, imagine cue 2 has data that puts the hard-edge fixtures in yellow with a breakup gobo and cue 3 is the verse cue. In cue 3 there is no change for these hard-edge fixtures except position. When you later copy cue 3 to cue 10 (after the chorus), then the hard-edge fixtures will be tracking from cue 9. If cue 9 has these fixtures in blue with no gobo, then your copied cue will look very different than the original cue! Most consoles have a copy option where you can select to copy the “state” of cue 3. This means that when you copy it to cue 10, it will copy not just the data in cue 3, but it will also copy the entire stage look that is presented when cue 3 is played. It is very important to understand what you are copying, and what the ramifications of that copy function will be.
Parameter Copying
Quite often I find myself copying fixture parameter data from one fixture to another or from one range of fixtures to another. This work is done in my programmer/editor, or even when directly editing cues that were previously recorded. Depending on your console syntax, you will have to know if you need to select the destination or source fixtures first. When copying data, consoles almost always allow you to copy the entire fixture, or you can select particular parameters to copy. I often will copy the color of a group of fixtures to another group of fixtures but leave the other attributes un-copied.
When copying parameters from one fixture to another, it is important to be aware of your console’s procedures. Some consoles will copy parameters based on generic parameter descriptions, while others will copy direct DMX values only. The latter can result in unexpected values when copying between different fixture types. For instance, copying the strobe setting from one manufacturer’s fixture to another’s could result in control command values being applied to the destination fixtures. There is nothing worse than accidentally dousing the lamps on a group of fixtures!
Another handy feature when copying parameters of fixtures is the order of fixture selection. Most automated lighting consoles will utilize the order in which you select fixtures to determine the copying order as well. So if you select fixtures 1 thru 5 and copy them to fixtures 10 thru 6, then fixtures 5 and 6 will be the same, 4 and 7, etc. This enables you to very quickly create some dynamic looks by thinking about how the copy will be applied. Furthermore, when copying timing values you can utilize similar techniques to create very fluid movements and transitions. In fact you can usually copy fixtures to themselves to change the order their parameters appear: 1 thru 5 copy to 5 thru 1, or 1 thru 5 copy to 2 thru 5+1, etc.
Copying with Style
My favorite use of copying syntax is when I am able to quickly pull elements from a previously recorded cue into the current cue I am working on. For example, if the LD asks for the strobe look from cue 3 to be added to the current cue, I can quickly tell my console to copy the strobe values from cue 3 to the current cue I am working on (or into the programmer/editor).
Another example is when I am able to copy a video setting for a media server or a gobo wash on a cyc into my editor, make a quick change and record this as a new cue. I save myself the trouble of grabbing the fixtures, positioning them, selecting gobos, modes, options, keystone settings, etc by just copying the data from an earlier cue.
Yes, I might have much of this data in palettes and the palettes will get copied as well as any hard coded data. However, I will save a great deal of time by recalling all the various settings in one single move rather than rebuilding the basic blocks and then making a small change. This methodology does not work in all situations, but it is a super tool to have in your bag. Anytime you can speed up your programming while being more efficient with the cueing, the LD (and you) will be much happier.
What NOT to Copy
There are certain elements of a show file that you should never copy. If you are the programmer for the opening act of a concert, you should not copy cues from the main act and use them as your own! Additionally, when working in a shared venue, it is not a good idea to copy another person’s show file and make subtle changes. Then you are back to copying the work of others, which you should have been taught is wrong from a very early age.
Copy Copy
If you are not familiar with the power of your console’s copy commands, then I suggest you start practicing. Many times when programming, copying can be a powerful tool to assist in getting cues written faster. Whether copying cues, parameter setting, setup options, or other vital data, remember that copying provides a quick way to restore previous work. Sometimes you need to be aware of the consequences of your copies due to tracking or timing changes. Sometimes you can simply copy data and reuse things that you previously built. Either way, I am sure that you will find copying a useful part of your programming experience.
