Clone cues

I am not privy to how the software works but I cannot imagine, even in these days of memory plenty, that the console has storage for the full information for a lighting look in every possible decimal cue slot and move data around wholesale when cues are renumbered. It is far more likely to store looks in the order they were created and keep a ‘look-up’ or index table so it knows where to find the data when a particular cue or step is required. 

Assuming this is the case there is no reason why several cues can’t refer to the same look data. If there was an easy way to make this available to the user it would save a vast amount of programming time. I can imagine perhaps that when you copy a cue it gives the option of a ‘hard’ or ‘soft’ copy. For hard copies a new look is stored identical to the one being copied. Soft copies (Déja Cues!) refer to the original look and when that is edited all soft copies or ‘clones’ change too. There would have to be a warning to this effect.

On the AV consoles this would be particularly valuable because it is a real pain having ‘hard’ lighting values attached to each sound cue all of which which would have to be changed if the look wasn’t right. It is often desirable to rehearse with sound before the production is ready for lighting.

  • Second thoughts - instead of having ‘soft’ copies of existing cues, you could use ‘soft’ copies of playbacks. When you are about to store a cue, the [Include] option allows you to store a playback’s look as the cue’s look. Then when you update the playback content all cues are updated. This is much more akin to how many people build cues on desks with submasters or use palettes. In place of the little ‘sun’, x/y and beam symbols the cue list would just show the parent playback number.

Related