A Better Way to Program to Tracked Music?

Hello,

I am coming from a background of being familiar with 3D animation and am coming to light designing for theatre, specifically for a tracked musical. Something I've found is that there isn't a cue editor screen that helps me program 20-30 cues at specific times after an initial "Go" button is pressed to start the song through MIDI at Qlab. I am able to achieve what I want by using .1-second follows with precise delays, but it's just not an ideal way to work. It's not an ideal way to work because I don't want to think about this like it's a cue list. I would much rather think about it like keyframes in animation. I think the critical difference is that theatre is all about cueing (so live things happening on stage triggers events in the board through direct observation of a human stage manager), while what I'm doing is no different from animation (there is one "go" and everything else that happens is completely predetermined exclusively by timecode). So when your events are triggered exclusively by timecode, you really want an editor that allows you to create and modify events, not snapshots/cues. So a cue is a snapshot, or a look. In animation world, you never, ever want to think about things like separate "looks" (because you want start/finishes of movements to overlap). You want an editor that allows you to manipulate things with exclusive respect to time. What you want is a scrub bar, honestly. A scrub bar is impossible and completely contradictory to the idea of live cueing, but it's a staple of animation. 

Is there validity to the idea of wanting to have an event editor specifically designed to think about controlling lights the way you control an armature in 3d animation? 

In other words, the exact thing I'm talking about is a dope sheet. I want a dope sheet. What a dope sheet does is it's basically a graph that tells you exactly when each parameter is changed with respect to time. It's unlike the blind spreadsheet because the blind spreadsheet thinks about cues, not timecode. I need something that thinks about timecode because working with cues that are automated to fire at specific times forces me to compartmentalize the song and I definitely don't like doing that. I don't like doing that because that's not how you write music. 

I want to be able to think about time like it's a constantly flowing river. I don't want to think about time like it's all these different, separate chunks. 

Ideally, there would be an editor screen that lets me set the length of the song, the cue number that fires this entire sequence I'm about to create for this song, and a workspace with a scrub bar that lets me create keyframes. 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. And I want that to be completely separate from all other events. This editor would deal with effects by allowing you to just drag and drop an effect to a channel and control whether that effect is off or on at a certain time with a simple on/off button. "Effect on" and "effect off" actions would be represented on the dope sheet just like any other keyframe. There would also be a way to load the actual music into this editor you you can scrub through the light show and the music in unison. The board would obviously need a way to output sound though of course, which isn't something all boards can do, I don't believe. 

The advantage of this is that it would make it 10x easier for people to get interested in creating advanced light shows in theatre. I'm noticing that very few light designers seem to do this sort of thing in theatre and I think that may be because the light board software is not at all conducive to this type of programming. It's great for busking and for cueing, but it's clearly not designed for thinking about events exclusively with respect to timecode. This is a very valuable idea to incorporate into this software because I don't know if anyone else has noticed, but there are a lot of theatre musicals that are tracked. Not having a dedicated editing screen to take advantage of tracked music seems to be a huge missed opportunity. Doesn't make sense not to borrow from animation world. This might be a possible reason why lighting in so many theatre musicals is so boring. It's not being thought about the correct way. If the music in your musical is tracked, there's really no good reason not to put on a proper light show. 

I see all these super advanced light shows on YouTube with hundreds of movers that are synced flawlessly to music and I don't know what software they're using, but I seriously doubt they're thinking about what they're doing in terms of cues/snapshots. You can only be that effective with your synchronization if you're thinking about it like an animator. I mean think about syncing individual light flashes that happen at the very end of the song—you want to wait through the entire song every time you want to check your timing just for the last part? God, please give me a scrub bar!

Parents
  •   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.

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

Reply
  • 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.

Children
No Data
Related