[QLab] Jumping into cues for a tech
Rich Walsh
point in a series of cues?
I'm finding that directors who do films expect the kind of response
you can get in Pro Tools: drop in on any line of your choosing and
immediately have all the audio playing exactly how it would be at that
point in the show. Trouble is, if it's in the middle of a five-minute
scene underscored by an approaching crowd, I'll have half-a-dozen
separate cues that each have to reach completion before that point,
eg: start the crowd in the distance, bump it up so it can be heard
when it's referred to, dip it back out of the way, change the EQ &
reverb on it as it moves closer, build it as it moves closer still,
fatten it up with extra audio files as you start to hear more detail,
pan it across the stage, and so on. All of these happen on cue points,
so it's not a single "sequence". Hence, you can't load to time: you
have to load each cue to just before completion, run it, load the next
one, run it, and so on - which takes too long. It's never as simple as
a single audio file and a string of absolute fades, meaning that you'd
just need to start the file and GO the last Fade Cue.
It's even worse if they want to pick up in the middle of a long fade
as there appears to be a bug in the pausing routines for fades under
Snow Leopard: you can start a fade running and then pause all, but
when you unpause all, the fade jumps to completion. To test that, try
fading in some tone and looking at the meters on the desk: they will
be higher when you unpause the fade than when you paused it... This
doesn't seem to happen in Leopard though.
I thought there might be a clever way of linking all the cues together
so you could load to time in the middle of a long string of separate
cues - but any combination of events that will allow QLab to load a
sequence to time makes QLab skip the whole sequence when standing by
for the next cue. So, if you link Q1 & Q2 together so you can load to
time in the Q1/Q2 string of events, when you GO Q1 you'll be stood by
for Q3, not Q2.
Have any of you developed techniques for dealing with this issue?
The best idea I've got is (unsurprisingly) a script that would
temporarily change the last cue in each selected sequence to be an
auto-follow, load the last selected cue to a time of your choosing and
then change all the cues back to do-not-continue - but it would be
kind of clunky, and difficult to work out the time to load to. It is
interesting that you can load a "fire all children simultaneously"
Group Cue to time, but you can't query the Group Cue for its duration.
If you could, then you could figure out the total time and load to,
say, 30s into the last cue in the string of cues. Should I just work
that script up into reality?
Thanks for any insights.
Rich
________________________________________________________
WHEN REPLYING, PLEASE QUOTE ONLY WHAT YOU NEED. Thanks!
Change your preferences or unsubscribe here:
http://lists.figure53.com/listinfo.cgi/qlab-figure53.com
Steven Devino
In this situation would it make sense to just render your lab file to a recording for the sake of rehearsal?
It would be interesting to see what the director values for rehearsal vs live. Also the only reason to use qlab in this situation is the dynamics of real time assembly plus reacting to live action. So maybe some hybrid form for rehearsal would make sense Hard to judge the situation from afar of course
Steve Devino
Mobile
Rich Walsh
> In this situation would it make sense to just render your lab file
> to a recording for the sake of rehearsal?
>
> It would be interesting to see what the director values for
> rehearsal vs live. Also the only reason to use qlab in this
> situation is the dynamics of real time assembly plus reacting to
> live action. So maybe some hybrid form for rehearsal would make
> sense Hard to judge the situation from afar of course
Being able to render the file would require fixed timings - which
would mean you could make it all into a single sequence anyway. The
problem is, it's a string of cues that all happen on variable cue
points: "real time assembly" as you say.
This issue keeps coming up for me during techs and post-preview notes:
at which time we are trying to get the "live" version sorted out, so
reverting to a "rehearsal" version to mark the cues wouldn't allow me
to judge levels, timings and interaction with other events (such as
the crowd becoming live and rushing onstage).
Often, these sequences start life in Pro Tools in the rehearsal room
and then get broken down into vampable events to allow for realtime
cueing in the theatre. I need to find a way of keeping the flexible
cueing (and working on the final version) without forsaking the
ability to navigate the string of cues quickly.
*
flexibility to meets the directors vision (QLAB & NOT PT), you need TIME
to make it happen.
To my knowledge there is no such thing is LLT for lighting. No LLT for
sets. No LLT for actors. No load in / load out LLT. All real time & no
jumping ahead...
Somethings require real time to test. Some things require multiple passes
& trying to find a work around is leaving the "sound designer" chair &
becoming a programmer which might or might not be a good thing.
Directors have a right to ask if something is possible & designers have a
right & mandate to say, "no, not at this point" sometimes.
With that said, Qlab will get better over time from these requests &
eventually, I can see how a "global time line view" might be some sort of
hybrid between DAW & Qlab. A visual way of seeing all the dominos fall
down.
My 2 cents.
*
On Sun, June 20, 2010 10:09 am, Rich Walsh wrote:
I need to find a way of keeping the flexible
> cueing (and working on the final version) without forsaking the
> ability to navigate the string of cues quickly.
Sean Dougall
I'm not sure if this would be helpful, but one possible alternative approach would be to set post waits that correspond roughly to the timing you would expect if you were to use auto-continues to make the whole scene into one long sequence. If you don't have auto-continue (or auto-follow) set, those post waits won't have any effect other than counting down visually. But if you need to load to a specific time, you can set the preceding cues/sequences to auto-continue, and load that whole sequence to time. As long as you don't include the upcoming cues/sequences, you should be able to rehearse from that point on, and you'll just need to remember to disable those auto-continues afterward. (Does that make sense?)
Sean
On Jun 20, 2010, at 7:28 AM, Rich Walsh wrote:
> The best idea I've got is (unsurprisingly) a script that would temporarily change the last cue in each selected sequence to be an auto-follow, load the last selected cue to a time of your choosing and then change all the cues back to do-not-continue - but it would be kind of clunky, and difficult to work out the time to load to.
________________________________________________________
vengb
On Jun 20, 2010, at 11:09 AM, Rich Walsh wrote:
> On 20 Jun 2010, at 16:01, Steven Devino wrote:
>
>> In this situation would it make sense to just render your lab file
>> to a recording for the sake of rehearsal?
>
> Being able to render the file would require fixed timings - which
> would mean you could make it all into a single sequence anyway. The
> problem is, it's a string of cues that all happen on variable cue
> points: "real time assembly" as you say.
>
> This issue keeps coming up for me during techs and post-preview
> notes: at which time we are trying to get the "live" version sorted
> out, so reverting to a "rehearsal" version to mark the cues
> wouldn't allow me to judge levels, timings and interaction with
> other events (such as the crowd becoming live and rushing onstage).
Perhaps for rehearsals, have both on hand. off to teh side a rendered
version of the most recent show version to run through pivking up in
the middle with things roughly in place and running for the
director's need of that ability, and the live qlab version ready to
go at any point to start from some cue point.
J. Vengrouskie
Soundscenes DC
Everybody does better when everybody does better.
Jeremy Lee
It's always clunky to do this. If the actors had built-in SMPTE generators, we could do all of this and more, but evolution has not brought us to that point yet. I generally just try and approximate it all, crash through fades that I don't need at that point, etc. If you can find a magic bullet for this, that would be fantastic!
On Jun 20, 2010, at 10:28 AM, Rich Walsh wrote:
> Have any of you developed techniques for dealing with this issue?
--
Jeremy Lee
Sound Designer, NYC - USA 829
http://www.jjlee.com
Leon Rothenberg
film director has to get used to when doing theater.
But I have found that:
-Directors don't care if you are in the exact correct sound state,
usually an approximation will do.
-It is usually pretty clear where we are going back to, and the
operator can start setting up ahead of time, wasting as little time as
possible. I always put QLab on a VCA or control group so we can do
this w/o everyone having to listen.
-I have taken to xfading and re-triggering long ambiances at certain
"key frame" moments, so that starting from so-and-so's entrance just
means firing one cue, instead of running a sequence of fades and
moves. This is actually less complicated to manage than it sounds.
-Banging through fade cues before the previous fade has completed
still gets you pretty close.
-If you absolutely need to check a level, make them wait. But again, I
am not sure we get more info than an approximation in the stop/start
world of tech, its really during a run where you get the best info.
Another good use for the VCA.
That being said, I always thought that a "Finish Fade Now" option in
the tools would be great, allowing one to jump to the end level of a
2m f/d.
Apropos, is there a way to turn on or off "Live Fade Preview" globally?
-Leon
Christopher Ashworth
On Jun 21, 2010, at 9:51 AM, Leon Rothenberg wrote:
>
> Apropos, is there a way to turn on or off "Live Fade Preview" globally?
Not at the moment.
-C
Rich Walsh
> -Directors don't care if you are in the exact correct sound state,
> usually an approximation will do.
Oddly, the first time this came up with this particular director (who,
I might add, has been doing this for probably 30 years longer than I
have), was when we were teching the change out of a scene underscored
by rain from a point c10s before the end of the scene and we didn't
get the rain running in time; it was not acceptable to live without it
for the sake of speed... Trying to crash through the cues with the
software I was using at the time I crashed the machine and wasted 20
minutes failing to reboot it instead... I tried to explore the
differences between using a non-linear system to provide sound for a
linear medium (Pro Tools and film) and using a linear system to
provide sound for a non-linear medium (playback software that can
handle cue points and theatre), but to no avail.
> -It is usually pretty clear where we are going back to, and the
> operator can start setting up ahead of time, wasting as little time
> as possible. I always put QLab on a VCA or control group so we can
> do this w/o everyone having to listen.
It's a nice idea, but often I am trying to edit whilst we reset - and,
we may not know where we are resetting to more than a few seconds
before we are expected to pick up. Lighting can jump directly to the
appropriate state, as long as it's not mid-fade (even if it is, it
will only be between two fixed, completely-known states - we're a bit
more Heisenberg...). "Waiting for sound" is not an announcement we
particularly want to hear.
I don't think it is unreasonable for a director to be frustrated if it
takes more than a few seconds to cue up for picking up on a particular
line; I believe the onus is on me to find a way to do that as
efficiently as possible so that 50+ people aren't hanging around
waiting for me.
> -I have taken to xfading and re-triggering long ambiances at certain
> "key frame" moments, so that starting from so-and-so's entrance just
> means firing one cue, instead of running a sequence of fades and
> moves. This is actually less complicated to manage than it sounds.
That is a _really good idea_ that I will attempt to steal in future!
> -Banging through fade cues before the previous fade has completed
> still gets you pretty close.
Yes - but how to do it as quickly as possible? See below...
> -If you absolutely need to check a level, make them wait. But again,
> I am not sure we get more info than an approximation in the stop/
> start world of tech, its really during a run where you get the best
> info. Another good use for the VCA.
Levels, maybe not - but timings, definitely. I would not want to be
teching with anything other than the "final" version of the show.
> That being said, I always thought that a "Finish Fade Now" option in
> the tools would be great, allowing one to jump to the end level of a
> 2m f/d.
Try this on a Hot Key (I think it works); "F" would be the obvious
choice:
set userDuration to 1 -- This is the time the fade(s) will be forced
to complete in
set fadeCues to {}
set originalPreWaits to {}
set originalDurations to {}
set originalContinueModes to {}
tell front workspace
repeat with eachCue in (selected as list) -- Extract just the Fade
Cues
if q type of eachCue is "Fade" then
set end of fadeCues to eachCue
end if
end repeat
repeat with eachCue in fadeCues
stop eachCue
set end of originalPreWaits to pre wait of eachCue
set end of originalDurations to duration of eachCue
set end of originalContinueModes to continue mode of eachCue
set pre wait of eachCue to 0
set duration of eachCue to userDuration
set continue mode of eachCue to do_not_continue
start eachCue
end repeat
delay userDuration + 0.1 -- Give the cue(s) time to complete before
resetting to the original variables
repeat with i from 1 to count fadeCues
set eachCue to item i of fadeCues
stop eachCue -- In case of Post Wait…
set pre wait of eachCue to item i of originalPreWaits
set duration of eachCue to item i of originalDurations
set continue mode of eachCue to item i of originalContinueModes
end repeat
end tell
I have modified an existing script to make it more obvious that you
can select a bunch of cues, load them all to a time, and then start
them en masse (which you could have done with "v" before anyway);
which goes some way to solving the problem:
-- Declarations
global dialogTitle
set dialogTitle to "Load to time"
-- Get the time
try
set clipboardContents to the clipboard -- The time requested
previously will have been copied to the Clipboard, and may still be on
there
on error
set clipboardContents to ""
end try
if (count paragraphs of clipboardContents) > 1 or (count words of
clipboardContents) > 2 or ¬
((count words of clipboardContents) > 1 and clipboardContents does
not contain ":") then -- Slight protection against spurious Clipboard
contents
set clipboardContents to ""
end if
set theText to ""
repeat until theText is not ""
set {theText, theButton} to {text returned, button returned} of
(display dialog "Load selected cues to this time (seconds or
minutes:seconds):" with title dialogTitle with icon 1 ¬
default answer clipboardContents buttons {"Start the cues too",
"Cancel", "OK"} default button "OK" cancel button "Cancel")
set clipboardContents to ""
try
set theTime to theText as number
if theTime is less than 0 then
set theText to ""
end if
on error
if theText contains ":" then
try
set currentTIDs to AppleScript's text item delimiters
set AppleScript's text item delimiters to ":"
set theMinutes to word 1 of theText
set theSeconds to rest of words of theText as string
set AppleScript's text item delimiters to currentTIDs
set theTime to (theMinutes as number) * 60 + (theSeconds as number)
on error
set theText to ""
end try
else
set theText to ""
end if
end try
end repeat
-- Copy it to the Clipboard and load
set the clipboard to theText
tell front workspace
load selected time theTime
if theButton is "Start the cues too" then
start selected
end if
end tell
Finally, since the solution to my problem is essentially the ability
to grab a whole load of cues, load the last one to time and have the
others load to their own respective completion times before starting
the whole lot, I have written a new script:
-- This script is UNTESTED! It rather assumes that you are working in
such a way that every cue that is triggered by a manual GO is a Group
Cue
-- ("Fire first child and go to next cue" or "Fire all children
simultaneously"), and that these Group Cues have a Post Wait of 0
tell application "QLab"
-- Declarations
global dialogTitle
set dialogTitle to "Jump into a string of cues"
tell front workspace
-- Check more than one cue selected
try
set selectedCues to items 1 thru -2 of (selected as list)
on error
display dialog "You need to select more than one cue!" with title
dialogTitle with icon 0 buttons {"OK"} default button "OK" giving up
after 5
return
end try
-- Get the time
try
set clipboardContents to the clipboard -- The time requested
previously will have been copied to the Clipboard, and may still be on
there
on error
set clipboardContents to ""
end try
if (count paragraphs of clipboardContents) > 1 or (count words of
clipboardContents) > 2 or ¬
((count words of clipboardContents) > 1 and clipboardContents does
not contain ":") then -- Slight protection against spurious Clipboard
contents
set clipboardContents to ""
end if
set theText to ""
repeat until theText is not ""
set theText to text returned of (display dialog "This script will
load the last cue in the selection to the time you enter below and
attempt " & ¬
"to load any other Group Cues selected so that any fades will
effectively have completed when you start the selected cues." & return
& return & ¬
"THIS IS NOT GUARANTEED TO WORK!" & return & return & ¬
"Enter the load time (seconds or minutes:seconds):" with title
dialogTitle with icon 1 ¬
default answer clipboardContents buttons {"Cancel", "OK"} default
button "OK" cancel button "Cancel")
set clipboardContents to ""
try
set theTime to theText as number
if theTime is less than 0 then
set theText to ""
end if
on error
if theText contains ":" then
try
set currentTIDs to AppleScript's text item delimiters
set AppleScript's text item delimiters to ":"
set theMinutes to word 1 of theText
set theSeconds to rest of words of theText as string
set AppleScript's text item delimiters to currentTIDs
set theTime to (theMinutes as number) * 60 + (theSeconds as
number)
on error
set theText to ""
end try
else
set theText to ""
end if
end try
end repeat
-- Copy it to the Clipboard
set the clipboard to theText
-- Work out the total time to which to load, and temporarily set
each Group Cue to auto-continue
set longestGroupTime to 0
repeat with eachCue in selectedCues
try -- This will skip cues that aren't Group Cues
set eachMode to mode of eachCue
if eachMode is fire_first_go_to_next_cue then
set groupTime to 0
set longestFadeTime to 0
repeat with eachChild in cues of eachCue
set groupTime to groupTime + (pre wait of eachChild)
set eachContinueMode to continue mode of eachChild
if eachContinueMode is auto_continue then
set groupTime to groupTime + (post wait of eachChild)
if q type of eachChild is "Fade" then
set eachFadeTime to duration of eachChild
if eachFadeTime > longestFadeTime then
set longestFadeTime to eachFadeTime
end if
end if
else
if eachContinueMode is auto_follow then
set groupTime to groupTime + (duration of eachChild)
end if
end if
end repeat
set groupTime to groupTime + longestFadeTime
else if eachMode is fire_all then
set fadeCues to (every cue of eachCue whose q type is "Fade")
set longestFadeTime to 0
repeat with eachChild in fadeCues
set eachFadeTime to (pre wait of eachChild) + (duration of
eachChild)
if eachFadeTime > longestFadeTime then
set longestFadeTime to eachFadeTime
end if
end repeat
set groupTime to longestFadeTime
end if
if groupTime > longestGroupTime then
set longestGroupTime to groupTime
end if
set continue mode of eachCue to auto_continue
end try
end repeat
-- Temporarily change Post Wait of penultimate cue in selection so
that when the string is loaded all other cues will "complete"
set lastPost to post wait of last item of selectedCues
set post wait of last item of selectedCues to longestGroupTime
-- Load the cue string and prompt to start it
load first item of selectedCues time longestGroupTime + theTime
try -- This means that the rest of the script will complete even if
the user cancels
display dialog "Ready to go?" with title dialogTitle with icon 1
buttons {"Cancel", "OK"} default button "OK" cancel button "Cancel"
start first item of selectedCues
end try
-- Reset the cues
repeat with eachCue in selectedCues
set continue mode of eachCue to do_not_continue
end repeat
set post wait of last item of selectedCues to lastPost
end tell
end tell
This will eventually be a Hot Key script, but for the purposes of
testing it needs to stay in Script Editor (hence the "tell application
"QLab"" block).
Unfortunately, this is conceptually quite tricky. I can't work out how
Chris has cracked the logic for the Load to Time slider, so I'm not
sure this script will cover all eventualities. However, initial
testing for my way of programming is promising. If anyone tries it
out, please let me know how you get on with it...
Rich
Andy Dolph
that essentially makes all fade times instant while it's engaged, but
doesn't effect the programing.
Andy
On Mon, Jun 21, 2010 at 9:51 AM, Leon Rothenberg <li...@klaxson.net> wrote:
> That being said, I always thought that a "Finish Fade Now" option in the
> tools would be great, allowing one to jump to the end level of a 2m f/d.
>
> Apropos, is there a way to turn on or off "Live Fade Preview" globally?
Richard B. Ingraham
> -----Original Message-----
> From: qlab-b...@lists.figure53.com [mailto:qlab-
> bou...@lists.figure53.com] On Behalf Of Rich Walsh
> Sent: Monday, June 21, 2010 10:58 PM
> To: Discussion and support for QLab users.
> Subject: Re: [QLab] Jumping into cues for a tech
>
> It's a nice idea, but often I am trying to edit whilst we reset - and,
> we may not know where we are resetting to more than a few seconds
> before we are expected to pick up. Lighting can jump directly to the
> appropriate state, as long as it's not mid-fade (even if it is, it
> will only be between two fixed, completely-known states - we're a bit
> more Heisenberg...). "Waiting for sound" is not an announcement we
> particularly want to hear.
>
> I don't think it is unreasonable for a director to be frustrated if it
> takes more than a few seconds to cue up for picking up on a particular
> line; I believe the onus is on me to find a way to do that as
> efficiently as possible so that 50+ people aren't hanging around
> waiting for me.
Rich,
I don't mean to hijack your thread here, but I feel like it's only
reasonable to say something. Or maybe a better way to put it is I couldn't
bite my tongue any longer. :-P
Why is it that Sound folks are so self conscious that at some point in the
tech process we might need everyone to wait for us to do something for a few
moments? Is it really that big of a deal? I don't mean this to sound
snobby or coy, I'm really asking here.
My thinking is this. I spend PLENTY of my time waiting for the lighting
designers to write their light cues. Occasionally I get to work with one
that works fast enough that I don't have time to doze off while they tinker
around forever and I'll still have all my sound cues written into the
playback software far ahead of where we are in the script. I also wait
around for scene changes, and costume quick changes, and all sorts of
nonsense. (don't get me started about when a choreographer starts using
tech for restaging or working on a dance number!)
So my inner voice says... well.... F' em.... they can wait for me every
once in a while as well. Yes I know, that's a poor attitude, but I'm only
half joking here. More times than not I'm working far faster than many of
my designer colleagues.
Having said all that, I do appreciate this discussion and obviously I'm in
no way against working out methods to speed up the process or make things
easier. I guess I've just become unashamed to ask for a tech to stop, while
I work something out with the director and I essentially have a big cast
sitting around while we make something work. If they do it for lights, and
they do if for scenery and costumes.... they can do it for me as well. Now
if it's something that is going to take forever I'm not going to ask
everyone to wait while I reinvent the wheel here. If I am holding things up
because I am unprepared and didn't have my rear in gear, well then shame on
me. But I'm not going to worry about a minute or two delay. If that's not
acceptable to the producers or directors, well then they can find some other
poor schmuck to design their sound. :-)
If they had to restore a whole bunch of scenery to do a scene change over
again, do they get upset about how long that takes as well, or how about if
the actors have to change back a costume? Those also take longer than the
simple jumping from one look to another that lighting does most of the time.
I don't see the difference, sorry. I do sound, not lights. It's not the
same thing. Some things I can do faster than them and some things they can
do faster than me.
For better or worse this thread essentially shows the one great flaw in the
deckless playback model for theatre sound playback that is used by both SFX,
QLab and others. If Rich was using a system that used something akin to
multiple tape decks you would just run the transport forward or backward on
those multiple decks and run the most recent level change cue, or maybe just
do it by hand.
My gut tells me that if this director has been doing it for over 30 years
longer than Rich has, he probably has nostalgia for the "old days" when they
just shuttled the tape a bit and the op would just move the faders to the
right spot. :-) Or maybe even further back to the days of phonographs?
LOL. There are still things that were easier back then, not many, but some
and this is one example.
Sorry for the rant....
Richard B. Ingraham
RBI Computers and Audio
http://www.rbicompaudio.20m.com
Jeremy Lee
> Waiting to set up the correct sound state is not the only thing that a film director has to get used to when doing theater.
Agreed- and lots of other good stuff.
> That being said, I always thought that a "Finish Fade Now" option in the tools would be great, allowing one to jump to the end level of a 2m f/d.
>
> Apropos, is there a way to turn on or off "Live Fade Preview" globally?
Both things that have been brought up before, and would be very useful. LCS has the complete all fades command, which is great. And I'm not a fan of the per-cue Fade Preview either...
Rich Walsh
>> That being said, I always thought that a "Finish Fade Now" option
>> in the tools would be great, allowing one to jump to the end level
>> of a 2m f/d.
>>
>> Apropos, is there a way to turn on or off "Live Fade Preview"
>> globally?
>
> Both things that have been brought up before, and would be very
> useful. LCS has the complete all fades command, which is great.
> And I'm not a fan of the per-cue Fade Preview either...
This will force any running Fade Cues to completion:
set userDuration to 1 -- This is the time the fade(s) will be forced
to complete in
tell front workspace
set fadeCues to {}
set originalPreWaits to {}
set originalDurations to {}
set originalContinueModes to {}
repeat with eachCue in (active cues as list) -- Extract just the Fade
Rich
sam kusnetz
richard ingraham wrote:
> Why is it that Sound folks are so self conscious that at some point in the
> tech process we might need everyone to wait for us to do something for a few
> moments? Is it really that big of a deal? I don't mean this to sound
> snobby or coy, I'm really asking here.
i am really glad to read your rant, richard, because i have often felt the very same way.
what i have observed is that directors and stage managers seem to have this feeling that lighting just takes up more time in tech than sound. i think this feeling probably stems from two facts: 1. that lighting technology was well ahead of sound technology for most of the 20th century, and so there was a time when this feeling was accurate, and 2. that a lot of sound design can be done "off line", by which i mean cues are produced before tech and therefore it seems like we really don't need much cueing time.
but i think the real trouble lies with us, because all the sound folks i know have this attitude of accepting the bias, and trying to work around it secretly and covertly. i do this myself, but i'm trying to do it less and less. at portland center stage, where i'm the production sound engineer, it took three musicals before i was able to tell the stage manager and director that we needed to hold for me to program a board move, or retouch an actor eq, or what have you. but now that we've gotten to that point, nobody bats an eye to hold for sound. it's a great feeling, and one that i am trying to bring with me to other theaters.
in short, i think the responsibility falls on us to patiently, politely shift the perception of tech rehearsal to include the brave new world of being happy to hold for sound.
"yes, i can take it from that line, please give me a few moments to pre-roll sound."
cheerio
sk
Rich Walsh
> "yes, i can take it from that line, please give me a few moments to
> pre-roll sound."
This is the essence of my original question: how to make those "few
moments" as short as possible. I'd rather be doing something
constructive when indulging the company's patience, not wasting their
time while I load cues. I haven't been chivvied along by Stage
Management whilst actually making noise for many years.
Perhaps the simplest solution is that when Chris considers bulk
modification of cues (such as having "C" affect all selected cues -
like "V" does - not just the last cue that was selected), grabbing a
bunch of cues and sliding the Load to Time slider treats them as if
they were a sequence and loads them all accordingly?
Rich
Christopher Ashworth
>
> Perhaps the simplest solution is that when Chris considers bulk modification of cues (such as having "C" affect all selected cues - like "V" does - not just the last cue that was selected), grabbing a bunch of cues and sliding the Load to Time slider treats them as if they were a sequence and loads them all accordingly?
Nice--I like that.
-C
Dominic Bilkey
D
Robert Kaplowitz
stepping thru many part sequences to be standing by for the next "go"
- example: scenes 1-3 are concurrent, temporally, so I create 3 nice
long beds of traffic-out-the-window. Those files, each, go thru a
series of builds and pulldowns in response to the text, many of them
"relative" rather than "absolute." Let's say there are 20 intermediary
cues between when they start and the transition out of scene 3. At the
end if that transition, they go away.
In the real world, this offers no challenges. But, in tech, we need to
run that transition maybe 6 times before we get it right.
Now, I have no problems having SM's hold for me (I've retrained the
old-school, grumpy ones, and befriended the new-school, "I understand
sound and projections" ones), but it is always a shame to have to step
thru 20 cues in order to get where I'm going.
I do use the playback controls to rush things in (because, of course,
I have 60 or 90 second fades on stuff) - this is nec, rather than just
hitting "go" a bunch because it's my perception that the last fade to
complete (rather than the lowest fade on the list) is the one that
counts...
So - for me, it'd be more useful to have a "next fade pre-empts"
option, but, again, this would be challenging with relative fades, as
it would somehow need to "look" at the levels above and do math...
Anyhoo - I don't quite see how Chris et al could make this work -
and i'm not suggesting that the other item is not a good idea - but I
do think it's a bit more complex than ya'll may think...
<><><><><><><><><><><>
-Rob Kaplowitz
Please forgive any malaprops - Steve Jobs insists that I really mean
to say "mango groves," not "microphones."
Christopher Ashworth
On Jun 26, 2010, at 1:28 PM, Robert Kaplowitz wrote:
> In terms of a "complete all" - for me, the challenge is more about stepping thru many part sequences to be standing by for the next "go" - example: scenes 1-3 are concurrent, temporally, so I create 3 nice long beds of traffic-out-the-window. Those files, each, go thru a series of builds and pulldowns in response to the text, many of them "relative" rather than "absolute." Let's say there are 20 intermediary cues between when they start and the transition out of scene 3. At the end if that transition, they go away.
>
> In the real world, this offers no challenges. But, in tech, we need to run that transition maybe 6 times before we get it right.
>
> Now, I have no problems having SM's hold for me (I've retrained the old-school, grumpy ones, and befriended the new-school, "I understand sound and projections" ones), but it is always a shame to have to step thru 20 cues in order to get where I'm going.
>
> I do use the playback controls to rush things in (because, of course, I have 60 or 90 second fades on stuff) - this is nec, rather than just hitting "go" a bunch because it's my perception that the last fade to complete (rather than the lowest fade on the list) is the one that counts...
FWIW:
In the case of absolute fades, there is a "most recent one wins" policy, applied on a per-channel basis. e.g. if an absolute fade starts fading output channel 1, then it "owns" that channel until a different absolute fade begins to adjust it.
In the case of relative fades, an unlimited number of fades can be applied to the same channel at the same time, and all will continue to affect it simultaneously.
> So - for me, it'd be more useful to have a "next fade pre-empts" option, but, again, this would be challenging with relative fades, as it would somehow need to "look" at the levels above and do math...
>
> Anyhoo - I don't quite see how Chris et al could make this work - and i'm not suggesting that the other item is not a good idea - but I do think it's a bit more complex than ya'll may think...
It's definitely interesting. I can't quite tell yet exactly how complex it is, because I think I haven't yet fully internalized an understanding of the problem. As such, I continue to read these descriptions with interest.
-C
Rich Walsh
> In terms of a "complete all" - for me, the challenge is more about
> stepping thru many part sequences to be standing by for the next
> "go" - example: scenes 1-3 are concurrent, temporally, so I create 3
> nice long beds of traffic-out-the-window. Those files, each, go thru
> a series of builds and pulldowns in response to the text, many of
> them "relative" rather than "absolute." Let's say there are 20
> intermediary cues between when they start and the transition out of
> scene 3. At the end if that transition, they go away.
That is exactly what I was trying to describe: a linear string of cues
that are triggered at specific cue points that need to be rushed
through to the state they would be in if you had run the preceding
scenes in real time. This "rushing through" needs to be done as
quickly as possible, ideally quicker than stepping through each cue,
loading it to just before completion and hitting GO. I'm pretty sure
the script I posted will do exactly this: if each of your cues is a
Group Cue you can select the ones you want to have completed and they
will be loaded and triggered en masse.
I'm not sure what will happen with relative fades though - and there
appear to be some oddities in how QLab "loads to time" cues that have
no length (such as MIDI commands), in that they fire even if you have
loaded to a point past their firing time.
What are the advantages of using relative fades? I only occasionally
use them to perform a specific job (fade a Group, simultaneous fades -
building and panning at the same time), never for basic builds & dips.
If you are using absolute fades and dealing with a simple ambience of
one or two files that start together and get faded up and down all you
have to do is set those files playing and GO the last fade before the
point at which you are picking up; the audio may not be in exactly the
right place but it will be at the very level it would be at if you had
run everything in order.
This script will achieve that for any selected Fade Cues (loading the
fades to 1s before completion):
tell front workspace
repeat with eachCue in (selected as list)
if q type of eachCue is "Fade" then
if running of cue target of eachCue is false then
start cue target of eachCue
end if
set eachDuration to duration of eachCue
if eachDuration > 1 then
load eachCue time eachDuration - 1
end if
start eachCue
end if
end repeat
end tell
> So - for me, it'd be more useful to have a "next fade pre-empts"
> option, but, again, this would be challenging with relative fades,
> as it would somehow need to "look" at the levels above and do math...
I don't understand what you mean by "next fade pre-empts"; can you
explain?
Rich
Christopher Ashworth
> I'm not sure what will happen with relative fades though - and there appear to be some oddities in how QLab "loads to time" cues that have no length (such as MIDI commands), in that they fire even if you have loaded to a point past their firing time.
This was by choice, although I'm quite open to arguments that it was the wrong choice. (Or, I suppose, arguments that it was the right one.)
-C
Rich Walsh
> On Jun 29, 2010, at 7:50 AM, Rich Walsh wrote:
>
>> I'm not sure what will happen with relative fades though - and
>> there appear to be some oddities in how QLab "loads to time" cues
>> that have no length (such as MIDI commands), in that they fire even
>> if you have loaded to a point past their firing time.
>
> This was by choice, although I'm quite open to arguments that it was
> the wrong choice. (Or, I suppose, arguments that it was the right
> one.)
It seems counterintuitive to me. If it was the other way round, you
could always select all the cues that you need to fire and Preview
them - then you'd have the choice of loading past them. At the moment
you can't construct a sequence of MIDI Cues, Script Cues, Start Cues
(etc) and start in the middle without having the ones you've loaded
past fire all at once when you start the cue.
For example, say you have an MSC Cue that fires a lightning flash from
LX, followed a few seconds later by thunder in an Audio Cue: currently
you can't skip past the MSC Cue to just trigger the thunder (both
events will fire with the wrong relative timing). Or, if part of your
sequence arms another cue you can't load past that part. I'm sure
there are other better examples...
Rich
ole saustrup kristensen
>> I'm not sure what will happen with relative fades though - and there appear to be some oddities in how QLab "loads to time" cues that have no length (such as MIDI commands), in that they fire even if you have loaded to a point past their firing time.
>
> This was by choice, although I'm quite open to arguments that it was the wrong choice. (Or, I suppose, arguments that it was the right one.)
I really love the current behaviour - we use midi extensively to control the state of our infrared tracking software, and it is nice to skip into our elaborate cue sequences, without having to worry about the order of execution. this way we can go from the culmulative state of the middle of a scene with a zillion timed cues (midi with prewaits in fire-all groups)
best / o
Rich Walsh
http://figure53.com/wiki/index.php?title=QLab_Scripts_and_Macros#Jump_into_a_string_of_cues
I've also put a bunch of other stuff I've been fiddling with up on the wiki now. If you don't fancy a lot of copying & pasting, you can get all my Hot Key scripts in the template workspace on my website (www.allthatyouhear.com). I'm no longer testing them in Leopard though, by the way.
Do let me know if you find any bugs...