In the third of our experiments in the quest for minimalism in creating a setup for busking concert lighting, On Stage Lighting tackles Executors as a means of busking a show.
If you remember from previous busking experiments, Playbacks Only and Palettes Only, the purpose of these exercises to find solutions to particular problems that arise from a series of restrictive rules. As usual, we’ll be taking a simple show rig and deciding how to set up the lighting desk for maximum busking flexibility and ease of use – taking into account the restrictions we’ve set. This then forces us to look harder at both lighting design and playback reality on a gig, as well as some specific lighting desk functions and options. Not only is this a useful way of thinking about, and improving on, our own current busk setups but it also can lead to use becoming more flexible as a programmer and operator.
The overall theme of the restrictions is to limit the number of ‘things’ that can be programmed and used. These restrictions are deliberately tight but there is plenty of anecdotal evidence of equally tight situations in a real gig situations whether it is forced upon us by lack of time, skills or facilities. More on that later.
Each experiment focuses on a specific method and its related tools used in busking concert lighting. So far, we’ve looked at using playback faders and associated buttons, and busking in the Programmer using palettes. In this iteration, we’ll be looking at executors as our only means of controlling the rig during the shows.
What are Executors?
In modern lighting control, executors are triggers that make something happen. Either hardware buttons on the console or tiles on a touchscreen, executors can be programmed to do a range of things including fire a cue, select a group, start a macro or even serve as a proxy for other buttons on the desk. Executors as a concept stem from concert and club desks that had more “Go” interfaces in the hardware than fader playbacks. The triggers were useful for items that didn’t need an intensity control in your hand and didn’t benefit from a fader in any way. Today, pro consoles use these non-fader triggers to expand access to more things at once and even to allow flexibility for the operator to put functions in different places, including programming tools.
In this experiment, we’ll be basing our show around the Cham Sys Robe Demo Show as usual. We’ll also stick to the main Cham Sys method of providing executors – on-screen tiles that are touchable. Different makes and models of desks have different number of hardware executors and pagination, but we’ll really just be concentrating on the executor count and using a grid as our restriction.
Executors Only – The Rules
- – 8 x 8 Executor Grid giving 64 different items.
- – Interface for playback is ONLY via the executor grid.
- – No Grand Master, other faders, any other desk buttons or other Windows such as palettes.
- – Executors can be on-screen fader, cue, macro, special function or replace any other desk button.
- – As usual, key light and haze are assumed to be outside of the restrictions or the grid.
- – Programming of the Executor Only busk set up can be achieved using any buttons, tools availableincluding hardware controls etc. It would be pretty tricky to program 64 executors with limited access to any other part of the desk at that stage. Perhaps that restriction is for the future!
The aim of this rule set is to allow for a range of possibilities in playback using cues, palettes or a mixture of both. This allow for a range of solutions while still limiting the overall number of ‘things’ available. Remember that there are no hardware buttons available during playback so if you need them, they’ll need to be allocated to the “Chessboard Executor Grid”. This simulates playback from a single touchscreen interface, tablet-based remote app or OSC interface too. Again, while the experiment has imposed restrictions, they also resemble possible realities on a gig.
First Ideas, Playback Choices
At this stage in the through the process, it seems clear that we have two major options for playback using executors and a choice that will see future choices diverge when it comes to allocating the 64 slots. Although we can theoretically pick a combination of playback or palette methods for busking we have to be aware of the needs of each with regard to the rules.
Executors as playbacks
If we chose the majority of executors to be playbacks, we’ll need a greater number of cues, stacks and other playback tools to be available on the chessboard. This will require thought about flexibility otherwise we could end up with a lot of ‘static’ items that don’t allow us to build looks up. This can be mitigated through the use of partial records, taking in only certain attributes for each executor. This will eat up executors. The other option would be to stack up cues and use an executor as the Go, in a similar manner to the use of stacks for busking in our Playbacks Only experiment. The difficulties in stacking too much up and the restrictive nature of the single tile executors interface means that this option become less attractive. However, it remains a possibility.
Executors as palettes
In our Palettes Only experiment, we looked at the methods of busking in the programmer as a means of providing a fast and flexible busk setup. This still holds true with our executors venture, but remember that in the last experiment we used 30 tiles up on palettes alone. Busking in the programmer works best with some access to other hardware buttons on the desk so we’ll have to replicate those too, using up valuable slots. This may be a price worth paying for flexibility.
Given that we have NO scope for faders, or hardware buttons including the keypad, intensity control will be controlled directly from the execute grid. The most obvious was to do this is to use a screen-based fader. However, each fader will probably need to be two grid tiles deep, using two per intensity executor. Simply turning every group intensity into a fader, including the PAR colour washes may use up more spaces than we’d prefer in an ideal situation. Other options include simple on/off cues with a fade time or doubling up intensity palettes with other attributes not related to the PARs, for example.
Perhaps we should look at other playback needs and control methods before allocating intensities. It isn’t unreasonable to allow a minimum of 8 slots for intensities.
As with the previous experiments, media playback on the LED array has the potential to get big on us in terms of eating up executors. It is likely that we will opt to sacrifice total flexibility of the PixMap in order to reduce grid footprint. We can still give over at least 8 executor slots to the PIxmap to start with, we might need more as 8 seems quite mean at is stage.
In our palettes only experiment we allocated 6 Groups and 6 each of Col, Beam and Position. As a starting point, it would seem prudent to assume 8 for each of the above plus 8 FX . So, quite a lot really. Our chessboard of 64 slots is beginning to look quite generous given our previous 6 of each.
That leaves us with 8 executors still free.
As we don’t have the luxury of access to the desk’s hardware buttons during playback, we’d better allocate our final 8 to additional buttons such as Clear or Blind should we choose to run any busking activity directly in the programmer.
The choice to use Groups and Palettes rather than playback based executors is right now a matter for personal preference but one might argue that certain groups and palettes are already Auto created and therefore only need copying onto the executor.
Use of playbacks instead of palette executors has some advantages (such as the potential for a single Strobe on/off toggle rather than two). Also, as we considered in the Palettes Only version, being able to use Clear and Blind effectively is predicated on having other stuff playing back. We can also use further priority control if we wish too, something that isn’t possible in a palettes only setup.
Join me at the next update when we’ll look at some detail and decision making based on thoughts of how we might actually have to run the show.