A Better Way to Program to Tracked Music?

 jordanhenshaw this is a bit late to the show, but I have extensive experience programming with timecode on EOS, and other systems as well. If you're still running EOS and Timecode, I'd be happy to help out. While this is an older post, I figured I'd throw some responses anyway since this is a highly viewed article, but feel free to ask for more details.

I think a lot of the workflow you're looking for is available, however the toolset is different.

First is to understand that far more productions are not very tightly timed. It is part of live theater that things do not happen exactly when they're supposed to, people forget their lines, the flub the intro to a song, etc. With that as background, most lighting consoles are based around cues that are manually triggers, which is why most of the documentation and training you see is based around basic "Go" and basic timing. Now more and more shows are going to timecode -- from bands to churches, where every single performance is the same, down to the millisecond. If this is a good or bad thing is subjective. But I do a lot with timecoded events. I can assure you that complex, tightly synchronized shows are programmed on ETC EOS consoles. There just isn't as much training on it because it is, indeed, far more rare than shows running without timecode.

ETC has a great whitepaper that might help you understand why consoles work the way they do: https://www.etcconnect.com/workarea/DownloadAsset.aspx?id=10737461850 
Also Martin Professional did a great YouTube video on the topic as well at: https://www.youtube.com/watch?v=UZ_YAb0PqVo 

There is a lot in your workflow that can be adjusted for huge improvements, including:

When looking at tightly timed events, you want to be running SMPTE timecode (aka LTC). That timecode should be generated by whoever is responsible for whatever is going on, on stage. This could be a music director, conductor, stage manager, director, or for a dance exposition it might be simply the sound guy triggering the specific songs to be played. But this is 99% of the time NOT the lighting guy. That being said, of course you need to program in advance, so you'll want a way to program your cues. QLab is what a lot of people use, however I use CuePoints because its lighter weight (simple program), cheaper, and does exactly what I need it to do. My workflow is to have each song start with a different "hour" number, so song one is hour one, etc. This isn't required but does make life easier.

Timecode is the master clock for a performance, everybody should be listening to only one master clock (there are some exceptions to this rule).... Your events should trigger from this clock -- and you should avoid, when possible having derivative cues (avoid cues that trigger other cues -- again there are some exceptions). It isn't simply the start for "Song A" which then has lighting prescribed follow/hang/delay times, but rather 98% of your cues should be triggered from a specific timecode time.

Timecode can trigger cues, but it can also trigger things like macros. Additionally, a cue can be use to trigger any number of other things through "execute" such as another cue stack used for a specific effect loop, etc.

What you are referring to as events, generally will be a cue, for example, Cue 100 takes a fixture from 0 to 75% over 20 seconds. But when you have rapid sequences for a given fixture (or group of fixtures) often people will write effects which will bring all of the complexity of that sequence into a single lighting cue.

Each cue should be triggered by a specific timecode number -- this is something you can type in manually -- such as 100 timecode 00:10:02:02 and 101 timecode 00:10:02:10 -- or better yet you can simply "learn" the timecode for the cues. Once you have the cues, you can put the console into learn mode and every time you hit go on a cue it will learn the timecode into the cue.

When it comes to scrubbing, as you said, this is where is really comes into play. Using your audio playback device that can "scrub" the audio and timecode, you can jump back 10 seconds, hit play, and see everything progress. You don't have to listen to the entire track again. But since each cue triggers at a specific timecode time, you do need to "scrub back" to prior to the cue's timecode that you want to look at.

For scrubbing there are two types that come to mind -- the first is scrubbing the audio playback while writing cues; and the second is scrubbing in the scesne of adjusting when cues/events trigger. I use a Streamdeck (but you could do it from within EOS as a magic sheet or direct select) that controls CuePoints (over OSC) to play & pause audio, as well as scrub forward/backward in increments of 10 seconds and 1 minute -- and 99% of the time I grab the 10 second scrubber. I can pause, write a cue, scrub back 10 or 20 seconds, watch it trigger, and go back as much as I need to. When it comes to EOS and when events/cues trigger, I also have some macro buttons to adjust the timecode by 33, 100, 500 and 1000 ms (plus and minus) -- that way if I need to nudge my timecode around I can do so far faster and easier than nagivating a mouse to drag a point around. I use MS because it makes more sense to me, but you could do fractional seconds (.03, .1, .5, 1.0). The fastest you'll be able to manipulate is 33 ms, but in almost every venue you have more lag/latency between your front and back rows when it comes to audio delay, that adjusting things inside of that is pointless, becuase you're narrowing your "tightly sync" lighting cues to a few rows of seats.

Next, you also want to make sure you understand the difference between tracking and cue-only mode -- for example, when you talk about cues being discrete looks, it seems like you might be working from a cue-only perspective, that is where each cue is an island. Rather with tracking, anything happening will track through other cues until acted upon again later on. For example, I don't need to think about my house light levels except for when I want to change them. Once I set the house lights at the beginning, they will stay there until I tell the console to record a different level. This is true for all parameters. Unlike in 3D, I don't have to define when something will stop, I can simply start something, and then later on stop it - for example I can turn a light on in cue 2000 (or timecode 2:00:00:00) and then not have to define the end, but then say I decide at timecode 2:00:01:12 I want it to turn off, I can simply record a cue to take it out.

Along with tracking is to understand marking -- that is the concept that makes me not have to worry about what a light is doing before I turn it on. There is also a concept of auto-mark. A lot of programmers disable automarking to have better discrete control. But regardless the concept is that I don't have to worry about a light until I need it. I don't need to preset anything. So if in cue 1001 I want Group A to come on to 50% brightness in blue focused downstage, I can simple record that in cue 1001, and then MARK that group. That will effectively "behind the scenes" automatically move the focus and color in a prior cue, so when it comes on in cue 1001 it is already pointed in the correct location with the correct color. You can also not use marking, so that when it comes up in cue 1001, it will transition from whatever it was last doing into the current look -- so you'll see it pan/tilt and change colors if it was previously something different. This is a huge timesaver.

Next is to understand discrete-time -- that is the ability for the console to have different parameters change, in a single cue, at different timings. For example, I can have group A start moving immediately with the cue GO, and change position over 5 seconds, and color over 20 seconds, and intensity over 2 seconds. I can also have Group B delay for 20 seconds before doing anything. You can also easy spread your timings over a group - such as fixture 1 thru 10 [delay] 0-10 which would have the lights come on one second apart from eachother. Depending on what degree you'll want to go back and edit this later, other people will use Part cues instead of discrete timings -- by that each part has its own timing, but all fixtures/channels assigned to that part will have the same time. There is nothing that says you cannot have discrete timings within part cues either. Part cues all GO at the same time, but again, you can introduce delay to everything in the part, only select attributes in the part, or even only select fixtures with select paramters.

"I want to be able to say this channel's intensity should be 0 at this second and it should be at 75% 50 seconds later, and I want the interpolation to be quadratic." - That's real now. I have that. And basically everything else I was asking for, but better than I imagined.

"I want to be able to say this channel's intensity should be 0 at this second and it should be at 75% 50 seconds later, and I want the interpolation to be quadratic." - That's real now. I have that. And basically everything else I was asking for, but better than I imagined.