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

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

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

     

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

  • There are a lot of those cheap, trashy sequence-based DMX softwares out there, at least 5 prominent ones. My software is not DMX software, but OSC software. It's a companion tool for Eos, and the second module is for any pro lighting console equally. 

    Linear-playback-only, that's partly why the cheap & trashy DMX sequence-based softwares aren't popular. They force you to give up your $10-50,000 pro console. Mine doesn't. Keep as much of your existing Eos workflow as you want and if you're timecoding, use my tool as needed, alongside Eos, not in place of Eos.

Reply
  • There are a lot of those cheap, trashy sequence-based DMX softwares out there, at least 5 prominent ones. My software is not DMX software, but OSC software. It's a companion tool for Eos, and the second module is for any pro lighting console equally. 

    Linear-playback-only, that's partly why the cheap & trashy DMX sequence-based softwares aren't popular. They force you to give up your $10-50,000 pro console. Mine doesn't. Keep as much of your existing Eos workflow as you want and if you're timecoding, use my tool as needed, alongside Eos, not in place of Eos.

Children
No Data
Related