Timecode List Copy

No, you are not missing anything.   Written up to address.  Clearly when moving a cue list, the execute field should be moved with it.  But I'm curious... when you are copying a cue list, you'd expect to see all the SMPTE times copied as well all of the time?  So, now, on a specific SMPTE frame, you'd have two cue lists executing?  Just making sure.... ??

Thanks!

a

Yes.  But in our situation we would copy just for organization and then delete the source list. So the intent is not to have two duplicate lists chasing the same timecode. But to make organization easier. 

Also. In the PDF print SMPTE and Playback information do not exist. The SMPTE information would be critical for the recreating this show from paperwork. At last count we have 60 lists that chase timecode and are using 3 sources. Thank you so much timecode gateway. Can't do that on that German desk ;)

Yes.  But in our situation we would copy just for organization and then delete the source list. So the intent is not to have two duplicate lists chasing the same timecode. But to make organization easier. 

Also. In the PDF print SMPTE and Playback information do not exist. The SMPTE information would be critical for the recreating this show from paperwork. At last count we have 60 lists that chase timecode and are using 3 sources. Thank you so much timecode gateway. Can't do that on that German desk ;)

As I think about it. Maybe a move command would be better. That was the list only exists once. We have tried both move and copy and SMPTE times don't move with ether function. 

Yep, Ben, we've entered an SCR about the Move function.   We've left it open to decide what should happen to the information in that execute field on a copy to.  More pondering!!

:-)

a

After some more experience with this here is another situation to ponder: 

We have a stage that runs the same show via SMPTE but needs a daytime and nighttime version of the show. For programming a way to program one show version and then duplicate it for the second version and then adjust cues for intensity would be handy. 

My immediate thought is to use an inhibiting submaster.

For example: plot the show that involves more/brighter lighting, then re-plot the show but don't re-plot actual values. Instead, plot inhibit values into submasters.

Obviously I don't know your show, so don't know if that is appropriate...

For programming, how about this:

Two "Show" cue lists.

Create one cuelist (eg Night), using Presets for every cue as these can contain Intensity/Focus/Colour/Beam palettes. Number the Presets appropriately.

Now copy this cuelist to create the "Day" and update the Day/Night differences as either Absolute or 'new palette' data - breaking the link back to the "Night" Presets, but only for the differences.
- This way anything that applies to both shows (eg focus/colour/beam) automagically gets updated into both shows when updated later.

The issue is not the lists them selves. But copying the SMPTE event list.