A Better Way to Program to Tracked Music?

Also, even if a show isn't "tracked", per se, a lot of music directors use click tracks, which also let you program lights, albeit not as easily. 

Typically we have the audio department generate a timecode track using SMTPE Timecode, so everything stays in sync. Then you can feed that timecode into a show control gateway and record whatever events you want to trigger along that timecode track.  You can scrub this audio file in any audio playback software.  But yes, the concepts of cues and events remain.

There are lots of tutorials on youtube about designing shows to timecode, if you're interested.  Doesn't really matter the console... the concepts are all the same. Here is one: https://www.youtube.com/watch?v=DxskAMEQUJg

Different consoles implement their show control UIs in different ways.  The GrandMA is clearer and better organized than Eos in this respect, but all modern lighting consoles can get you to the same outcome. There is a lighting console that is entirely based around a timeline interface called the Jands Vista, but it's not particularly popular.

The most Musicals i know are play with Live-Music.
An Orchestra or a Band.
So in this case it is not helpfull have a prerecorded Timecodeshow.
Because it wil not work...

But i must say,.... i not really understand your problem...
Here is the Event Editor in EOS



You can manipulate Startpoints, what kind of Action you want at the choosen time.
In your Cue-List you can create Autofollows via Hang/Follow or Loop-Link, you can set Effects in a Cue, set Extermal Links (for Macros for example if you want- but you not need it because you can set Macros direct in the Event List), also for OSC Commands, Snapshots,.. (all you can Execute in a Cue

The EOS Event List does not interest what you have give in the Cue, the Event List will fire the Cue. You can manipulate the Cue himself whenever you want (also in Blind during running the Show)
Shure you can also fire Cue 2/X.. as Action in the Eventlist (EOS normal works with the Cue List you add at the Main Playback, but if you have a second Cue List on a Fader and you press in this List GO EOS will add this as Action).

What you not can do -direct- in EOS is skip back and forward in the Timecode signal via Playback buttons.
This you must do in your Player
(Maybe you can send an OSC Command for QLab that skip back-forward 10-20-.. seconds???)

What you can do is give in the Comand Line:
Event 1/ TIME 01:02:03:45
and EOS jumps to the specific point in your Eventlist.
(Without the "/" you will change direct the Timepoint for the Event Nr. 1)
If you switch INTERNAL at ON you can run from this point your List.
You can add this command also in a macro and jumps everytime to this point (but be carefull in this case the LEARN Button must switch OFF because if you stay in Learn Modus then you learn this Macro with every click new in your Event List)
If you get an External Signal and you jumps for 01:02:03:45 but your real Timecode stay at 00:01:02:34, EOS will also start the Event that comming at next Timecode point. And set the Timeline back at the synchron signal.
But you can jump around, play as you want...

If you have Internal AND External Timecode switch ON, EOS will wait for an external Timecode Signal.
If you STOP the External, EOS also stops.
If the External Signal get lost -and you have switch INTERNAL at ON- EOS will generate an own Clock (running time you see above every monitor change from green to red) and run with this internal Timecode Signal.
If you connect the external Signal new, EOS synchron by himself new.
If you switch ON only the internal, EOS will start from Zero (or the Start Point you have give with the Command Event 1/ TIME.....
If you have switch ON only the EXTERNAL Signal, EOS will wait until it get a signal.
All this switchers you can store in seperate Macros, add this Macro(s) at Submaster(s), attache this Submaster to one of your Fadersbuttons and you have direct access.

In LIVE in your PSD you can mark a Cue, click at TIMECODE Collum and then add a new Timcodepoint for when do the Cue get start


Only for change the Action you want fire at Timecode Point you must change to the Event Editor.
All other you can do in LIVE.
Also during running this Timecode Show.

Thanks for this information. I've been aware of the show control/event editor thing you've been talking about , but haven't been able to find a video tutorial on how to use it. But it's not really what I'm looking for anyway, I don't believe. Or maybe it is. I would really need to figure out how to make it work. I did play around with it, but didn't get anywhere: the question of how do I make this window listen to MIDI coming from Qlab on a different device, and how do I tell it which song I'm talking about seemed like a pretty tricky question to answer. 

In 9 of 10 case it is easy.

Connect QLab -for example- to your EOS.
Create an Eventlist via 1/ .
Activate in Show Control External at ON.
Set the Eventlist on LEARN (via LEARN Button same Button you also use for learn Macros)
Have a Cue-List on Main Playback
Press GO at QLab, see your Time runs in EOS
Ever you press GO on EOS you create automatic an Event in your List.
You can also start Macros, press Submaster.
You not need go straigh thru Cue-List. You can also work with Go To Q XY ENTER and EOS will record this Cue in the Eventlist.
This all will autorecord in your Eventlist
That all you can later edit as you want.

EOS will ever follow the external Timecode Signal.
Only you can`t skip back-forward in EOS.
For this you need your external Player.

You wanna get a "Timeline" as we know it from some Videoeditors?
And in this Timeline you can set marks for Events
Is this what you looking for?

Interesting. The guy in this video is indeed using a dope sheet at certain points. It also appears as though he has a way to scrub through the song inside the board itself. In ETC, with timecode syncing to a different device, I'm not sure if timecode information would "scrub" as well; that is, I'm not sure if you could jump to the middle of a song and start the lighting playback from there instead of having to start at the beginning of the song each and every time. 

What I'm noticing is that when working on ETC, the number of repetitive, redundant button clicks not contributing to the light design is almost as high as the number of button clicks that actually contribute to the design. The number of redundant button clicks is directly caused by 2 or 3 lines of code that are obtusely counterproductive and serve no rational purpose for my workflow. 

Counterproductive line 1: The line of code that demands that the currently selected fixture be deselected any time I switch modes. This results in at least 100 presses of the Select Last button per day. 

Counterproductive line 2: The line of code that demands that I be shown either the live table or a magic sheet every time I switch back into live. This easily results in 100 tab clicks per day just to get back to the 2 screens I'm using 90% of the time. 

Counterproductive line 3: The line of code that demands that I be shown the library of effects in place of my beloved ML editor every goddamned time I press Effect Effect. I have the effect library on my iPad through direct selects. I don't want it to be on the LCD's in place of my beloved ML editor. I also want the effect editor to automatically pop up so I don't have to go press the triangle to see it if I had the PSD maximized. 

What I noticed as I watched this guy programming on the MA console isn't what I observed, it's what I didn't observe: the console wasn't constantly changing up screens on him. Yes, he probably had slightly more screen real estate than I have, but the screens weren't constantly break dancing every time he switched modes. It wasn't the case that the entire look of the displays completely transformed just because he wanted to briefly edit an effect. The MA console appeared to be perfectly fine with giving him control of multiple types of things from the same screen layout without this constant break dancing between Live looks and Blind looks. 

What I've learned is that ETC's fascination with trying to predict what I want to see has a tendency to be extremely counterproductive over the course of an 8 hour programming session. The number of redundant button clicks needs to be heavily reduced by trimming the code that think it knows what I want to see (it doesn't). 

Huh. Very cool. I'll check this out on the board tomorrow! (Long boring weekend). Thanks!

Next Step:
If you have press wrong GO -means you set a wrong Timestamp- you can edit this in the Event List.
Via Event XY Time 01:02:03:46 (No,... you can`t set this time, because EOS have as maximum 30 Frames...*GGG*)
Or you do it in the PSD via Timecode Column
Or delete this wrong Event.
For create the new correct Timestamp jump on your player -QLab- at a Timeponit so EOS can play 1-2 Cues before you need the new Timestamp.
With this EOS will set automatic at the correct point in your Cue-List.
(Maybe this can be important for you for some Automark Moveinstructions)
Because EOS will play back all recorded Cue you have do.
Or you go for correct position in your Cue List with Go To Q XY
After this, don`t forget set the Event List at LEARN.
And at the correct Timestamp press GO.
EOS will insert a new Event in your List.
You can activate-deactivate the LEARN function every time you need/not need it.

If you have activate LEARN every press at Go or on a SubmasterMacro will create a new Event.

If your Event List maybe have100 Events you can also do:
EVENT 101 ENTER.
And then manipulate the Timestamp and the Action as you need.
EOS will sort this Event automatic at correct position.
(This means, you can´t move Event 10 to new position 20 via EVENT 10 MOVE TO 20 ENTER,... for change position you must change the Time they use. EOS autosort the Events by Timestamp)

You see, you have many many option for manipulate and edit your Event List

 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.

jordanhenshaw -- also for the benefit of you and others:

* Scrubbing timecode -- yes, ETC will be able to follow if your timecode is scrubbed around --- in the scene that it takes any SMPTE listener a few frames (microseconds) to figure out what the new time is, and then jump to the respective place. Now most consoles, including ETC EOS and GrandMA work on the concept of "triggers" so it will not immediately "scrub" the lighting look on stage, until it passes the next timecode event that it knows about. Because timecode does not have to be linear, it doesn't assume that because the time is 6:05 -- and that since there is a cue 90 @ 6:00 and a cue 91 @ 6:10, it does not infer that it should jump back to cue 90 in preparation to go to cue 91. In contrast to your 3D anaology, timecode in lighting does not have to be strictly linear. I can have cue 90 with timecode, and cue 91 without timecode (manually taken at the end of a song) and then cue 92 back in timecode. Also I can have cue 999 which can be triggered/taken at timecode 09:00 and 10:00, while tiemcode 9:01 goes to cue 9 and timecode 10:05 goes to cue 251, but I get the benefit to using cue 999 at the top of every minute.

* Counter productive #1, if you can provide an example of your exact keystrokes and what you're trying to accomplish, you might not need to be pressing select last a lot. I probably press that specific button a few times a session.

* Counter productive #2, this is a common request for people with limited realestate, but also because they're leaving live far more than they probably need to. I'm in blind extremely rarely during programming. Most of the time I'm in blind is because I want to make a blind change during a show, and when I press LIVE, I do need my Tab 1 & 2 the most prominent screens to help me navigate the show. What is bringing you out of live so much during a programming session?

* Counter productive #3, what do you think effect-effect should do? I think you're using this incorrectly. If you know what effect you want to apply, it can be simply Group 20 Effect 901 Enter. If you're looking to remove the ffect, it is simply Group 20 Effect at Enter

 

Thanks for the thorough reply. Times are changing. A lot. Since this post 2 years ago I have completely transformed what is possible when doing timecode on Eos. Nearly everything anyone knows about timecode on Eos right now will be thoroughly obsolete in 3 years. Basically everything explained in your post, while technically still true, and certainly still true outside the context of timecoding, will be obsolete quite soon and technically is already obsolete within the context of timecoding. I took what I wrote in the initial post here and built a house on top of it. 

First-principles goal is to delete 100% of time needed to focus on technicals so 100% of time and energy and focus can be spent on art. We're a long way off from that, but we're getting significantly closer. 

It's an exciting time.

"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.

jolson said:

Now most consoles, including ETC EOS and GrandMA work on the concept of "triggers" so it will not immediately "scrub" the lighting look on stage, until it passes the next timecode event that it knows about. Because timecode does not have to be linear, it doesn't assume that because the time is 6:05 -- and that since there is a cue 90 @ 6:00 and a cue 91 @ 6:10, it does not infer that it should jump back to cue 90 in preparation to go to cue 91. In contrast to your 3D anaology, timecode in lighting does not have to be strictly linear. I can have cue 90 with timecode, and cue 91 without timecode (manually taken at the end of a song) and then cue 92 back in timecode.

That's what I call "Livemap" in my software. If you start playing from 6:05, it will fire cue 90 with Go_to_Cue 90 Time :01 Enter if livemap is enabled. Otherwise it's super annoying to have to constantly scrub back just to get that cue to fire so you can see the stage as it should appear for the time period you're workshopping at the moment. But when working in the other module you never ever have to to worry about that type of problem ever because it uses the "absolute" control methodology as opposed to "undefined". 

There is one lighting software that I know of that does work on a true timeline basis that you're talking about called Lightforge by Visual Sorcery. It also allows you to load in audio files along side lighting cues.  It can also listen to MTC (MIDI time code) as well a SMPTE (LTC) module available upon request. It's great because even effects will play back exactly as you're looking for. I have used that software pretty extensively in the past. The biggest limitation is that it forces you into a linear playback, and working in a non-linear way (during production/show) doesn't work well at all. It basically requires you to always go forward from cue to cue. But it does make cue writing easier when it comes to working along side of audio. But when I look back at the total time to write cues for a tightly synchronized song, I am still faster (and can accomplish more in less time) on EOS compared to Lightforge.