On Stage Lighting presents a quick guide to the use of “nested” palettes in stage lighting programming and some benefits from using this technique, along with potential problems that may arise for the unwary programmer.
Remind me what palettes are again?
If you remember from previous articles, palettes in stage lighting programming are building blocks of individual attributes (colour, gobos etc.) used to create whole scenes, particularly in a complex environment such as using ‘intelligent’ lights. The cues themselves are recorded containing these referenced building blocks with the advantage of being able to edit individual blocks and thus change the programming across a cue or many other cues via a single point. Palettes are particular useful when touring shows because they allow quite simple changes to be made to programming such as position data, and these changes are reflected in all the cues using the palette during playback. Check out this on palettes but the key thing to remember is anything created using a palette is referencing the palette and not the underlying channel values that get sent as DMX (or other protocol) to the fixtures.
What are nested palettes?
Many professional lighting consoles not only have the ability to create palettes of individual attributes but that those palettes can also be created using other palettes. These are often referred to as nested palettes. Nested palettes also centralise information that you can reuse, but the generally idea is that a palette is made up of other palettes – sub-palettes, if you like. These are references within references. At the bottom, somewhere, is hard data and this is what you would edit in the future.
How would I use nested palettes?
The choice to use the functionality of nested palettes is very much down to the individual show and playback circumstances and what you’re trying to achieve. They can be useful both standard cue programming and also the programming of more complex palettes that can be used to recall particular looks instantly when busking a show. A nested palette is still a building block, but is a slightly more advanced technique than a simple palette that you would use to just get all your Washes to Red quickly before building that into a cue.
One example of using method palettes would be to create a palette that used a few different colours, one that you would like to recall instantly when for busking a show. This might be where you wanted these multiple colours to appear on stage at the press of one button. A colour ‘look’, if you like. You want your look to contain blues, greens and cyans on different fixtures and you could just go ahead and create this look palette that set up your fixtures with those colours and create them as a normal palette. However, you could also create a blue palette, a green palette and a cyan one. The benefits of doing this would be that should you wish to tweak the values of, say, the cyan for the whole show, you would be able to do it at the cyan palette and this would then reference forward to your look palette and any other palettes or cues using it.
Another example of using nested palettes would be to create a series palettes to call up gobos which would that contain individual gobo information but also focus the gobo to hard edge, again to be recalled with a single touch during the show – Hard Beam Splitter, Hard Dots etc. You could create many individual palettes each with their own beam edge setting via the Focus channel values straight into the palette. Alternatively, it would be more efficient to create Focus palette that hard-edged Gobo Wheel 1, with each individual gobo palette referencing the single Hard Edge palette setting. Again, a single edit to the Focus palette when tweaking the focus would alter all the other gobo recall palettes.
The biggest problem with the ability to create nested palettes in a professional lighting desk is the fact that you can,er, accidentally create them without realising it. This can catch you unaware while programming happily, away only to find later that you have created a lot of palettes within other palettes and then maybe even cues. A single edit at the base can suddenly wreck a lot of other stuff and then you have to trace the lineage backwards to fix it, so it is important to understand nested palettes if simply to avoid creating them accidentally.
When programming you should check the information in the programmer to ensure that the attribute data you’re recording is in fact not another palette but hard channel values IF you do not wish to create a nested palette. An example of this would be that you might create an original Blue palette, and then have that Blue continue to be active in the programmer while creating subsequent palettes and cues. This could really create big problems within your programming in that changes in other programming can ‘magically’ appear further down the palette family tree.
Another issue when trying to work with nested palettes is breaking the reference. This is the opposite of the previous issue of unwanted nesting. Palette references will be broken if you are editing a palette or a cue and those particular attributes that were once referencing another palette get accidentally overwritten with hard channel values. Basically, you are editing in the ‘wrong’ place. Avoiding this comes down to being aware of when a piece of programming is using a reference, where to edit that reference and general good housekeeping when programming, including checking the programmer values before making updates.
How do I create nested palettes?
On most lighting consoles, creating nested palettes is usually pretty straightforward and involves setting channel attributes in the programmer (or making them ‘active’) and then recording those attributes as a palette. When you wish to put that palette within another, calling it into the programmer during the creation of the next palette will generally ensure that the reference is maintained. Looking at the contents of a palette (on the screen, not on the stage) should confirm the reference, rather than ‘hard’ channel values.
Having found out a little bit more about nested palettes and also the pitfalls of accidentally creating them, perhaps you would like to have a go yourself. One thing we haven’t really talked about today is which attributes are being recorded or ignored during programming actions. This can a bit of a complex area and is dependent on your desk settings and how the attribute families (Colour, Beam, Postion etc.) are dealt with by default and is really within the scope of a future article. However, if you are experimenting with nested palettes and aren’t getting the results you hope for, a good place to look is how attributes are activated, recorded and attribute ‘masking’ is being applied plus how the desk is set up to behave once you have hit Record.
So, that’s about it for this quick rundown on using nested palettes in stage lighting programming.
There are times when using this techniques is a fantastic lifehack for a busy programmer and other times when it becomes a complete PITA. In that respect, the technique is very much like Tracking and those positive and negative aspects are, similarly, very much reliant on your understanding of the concept and the correct application of the tricks. Or being aware that there are tricks, and avoiding getting caught out by them.
Stop by and let us know in the comments if you have particular uses for nesting palettes in your own programming or if have any tips or tricks for other On Stage Lighting readers. When do you find nesting palettes most useful for you?
Image from Danny Ayers on Flickr