Method #1: Jam Sync SMPTE Sequences
See example .ws4 file below.
1. Use a single sequence with its timecode set to "Jam Sync."
2. "Arm" the Jam Synced SMPTE sequence so that it will actually follow timecode.
3. Add the events to the Jam Sync sequence at the SMPTE time you'd like them to execute.
4. These events added to the Jam Sync sequence can include starting other non-SMPTE sequences.
Method #2: Trigger Sequence with V16Pro.LTC
See Example file below.
1. Create a trigger for each sequence using "V16Pro.LTC = "
2. Events can be used directly in the sequence or start other sequences
Notes about Best Method:
Method #1 avoids any possibility of missing triggers should some external event prevent the SMPTE timecode from being read at that time.
For example, if an extreme amount of ethernet traffic flooded the network from a device that is specified in the script, it might delay processing for one frame.
In that case, the "trigger" wouldn't have have a chance to be compared to that exact SMPTE value. By the time the trigger was allowed to be processed, the SMPTE timecode might already be on the next frame and the trigger comparison would not match.
When using a "Jam Sync" sequence, events will "catch up" should a single frame of SMPTE be skipped. For a Jam Sync sequence, events will "catch up" up to six frames before "jumping over" to the new timecode value.
In other words, the V16Pro could be "busy" with other high priority items (like incoming ethernet traffic) for up to 6 frames with the Jam Sync sequence and still execute an event. If the V16Pro is busy for 1 frame with a SMPTE trigger, it's possible the trigger would not execute the sequence.
In most all cases, SMPTE triggers work just fine. It is only the possibility of large external effects on the controller (ethernet traffic, usb traffic, unplugged flash card, etc) that would cause a trigger skip. In this case, Jam Sync will help.