[QLab] Back To Dumb Questions
Rich Walsh
1. What is QLab actually doing when it loads media? Adding an audio
file seems very slow (compared to SFX), let alone opening a workspace
with lots of cues in it.
2. I'm still confused about the MSC implementation: GO does not appear
to support Q_list, yet STANDBY_+ (etc), do: "Move to the next cue and
load it. If a Q_list number is supplied, perform this action on the
specified cue list. Otherwise do it on the currently selected cue
list." Is this just a mistake in the manual? If not, how do you know
the Q_list number of a cue list - and why doesn't it work for GO cues?
3. I don't understand the "Maximum volume of any audio output"
setting. What does it do? I'm sure I read this somewhere, but I can't
find it now.
4. Is there a trick to activating a fader in a Fade Cue without
inadvertently moving it? Every time I try to click on one to turn it
on I end up changing the level!
5. Is there a way to get the way the cue list advances to behave like
SFX 5? I'd love to be able to turn off the intelligence with which
QLab jumps around follow-ons and stands you by for the next non-
automatic cue: sometimes you want to push through on a wait by going
the next cue in the dominoes before the one before topples; QLab just
jumps the whole stack of dominoes... We are a rep theatre, and every
time we changeover we "bang through the show" as quickly as possible
so we can hear everything, without having to wait for 5 minute
sequences to run in real time. I can't see how to do this in QLab
without having to scroll back up a bit each time you push GO.
Finally, a tip if you haven't already worked it out: you can of course
assign "missing" keyboard shortcuts to menu items (such as Copy Fade
Shape & Paste Fade Shape) using "Keyboard Shortcuts" on the "Keyboard
& Mouse" pane of System Preferences.
Thanks as ever.
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
Christopher Ashworth
On Sep 7, 2009, at 10:16 PM, Rich Walsh wrote:
> Sorry, but I have some more now I've been playing again:
>
> 1. What is QLab actually doing when it loads media? Adding an audio
> file seems very slow (compared to SFX), let alone opening a
> workspace with lots of cues in it.
Well, other than pasting in code I'm not sure the best way to answer
this question. :) It creates QTMovie objects from each file, for one
thing.
> 2. I'm still confused about the MSC implementation: GO does not
> appear to support Q_list, yet STANDBY_+ (etc), do: "Move to the next
> cue and load it. If a Q_list number is supplied, perform this action
> on the specified cue list. Otherwise do it on the currently selected
> cue list." Is this just a mistake in the manual? If not, how do you
> know the Q_list number of a cue list - and why doesn't it work for
> GO cues?
Let's see, to clarify, are we talking about incoming or outgoing MSC?
I think you mean incoming, but wanted to be sure. If so:
One thing to understand about MSC is that it must be interpreted a bit
to make the most sense in the context of the software that implements
it.
In the case of QLab:
The spec for MSC GO says it can optionally support a Q_number, a
Q_list, and a Q_path. In QLab, the MSC GO does support a Q_number so
you can specify which cue you want to fire. But the other two
parameters don't really make sense in QLab land. Yes, there are cue
lists, but specifying one in an MSC GO message doesn't mean anything
useful to QLab, because the Q_number fully specifies the cue you want
to fire, because it is always unique.
The spec for MSC STANDBY_+, in contrast, says it can optionally
support only a Q_list parameter, and in this case it does make sense
for QLab to support that parameter.
The Q_list number of a cue list is just the number of the cue, just
like any other cue. By default they have no number, but you can
assign them one if you need it, such as for giving them an ID for
incoming MSC.
> 3. I don't understand the "Maximum volume of any audio output"
> setting. What does it do? I'm sure I read this somewhere, but I
> can't find it now.
With relative fade cues it used to be possible to crank the volume on
an output up to an arbitrary level. This was bad. The max volume
will prevent this from happening.
> 4. Is there a trick to activating a fader in a Fade Cue without
> inadvertently moving it? Every time I try to click on one to turn it
> on I end up changing the level!
No trick currently. Feel free to make a ticket for me to work on
improving this:
http://tracker.figure53.com/qlab/
> 5. Is there a way to get the way the cue list advances to behave
> like SFX 5? I'd love to be able to turn off the intelligence with
> which QLab jumps around follow-ons and stands you by for the next
> non-automatic cue: sometimes you want to push through on a wait by
> going the next cue in the dominoes before the one before topples;
> QLab just jumps the whole stack of dominoes... We are a rep theatre,
> and every time we changeover we "bang through the show" as quickly
> as possible so we can hear everything, without having to wait for 5
> minute sequences to run in real time. I can't see how to do this in
> QLab without having to scroll back up a bit each time you push GO.
Hmmm....I need to think about this one more before attempting to
answer---and I am being stridently called to breakfast just at the
moment. :)
Cheers,
Chris
Andy Dolph
>> 5? I'd love to be able to turn off the intelligence with which QLab jumps
>> around follow-ons and stands you by for the next non-automatic cue:
>> sometimes you want to push through on a wait by going the next cue in the
>> dominoes before the one before topples; QLab just jumps the whole stack of
>> dominoes... We are a rep theatre, and every time we changeover we "bang
>> through the show" as quickly as possible so we can hear everything, without
>> having to wait for 5 minute sequences to run in real time. I can't see how
>> to do this in QLab without having to scroll back up a bit each time you push
>> GO.
>
> Hmmm....I need to think about this one more before attempting to
> answer---and I am being stridently called to breakfast just at the moment.
> :)
What about something equivalent of the "quickstep" mode on ETC
consoles? a special mode that lets you step through each cue with the
go button but temporarily makes all fade times 0 and in this case
would probably disable autocontinuing
Andy
Jeremy Lee
There's a position slider for every series of cues that autofollow.
So you can start your sequence, listen to it, be happy, then grab the
slider and advance it to where you want it, and continue from there.
WAY better than the SFX 5 method, since when you scroll around in this
way, you're actually completing all of the fades, etc. More like fast-
forwarding the tape than just moving the dominoes closer together.
Try it...
Best,
Jeremy
On Sep 7, 2009, at 10:16 PM, Rich Walsh wrote:
> 5. Is there a way to get the way the cue list advances to behave
> like SFX 5? I'd love to be able to turn off the intelligence with
> which QLab jumps around follow-ons and stands you by for the next
> non-automatic cue: sometimes you want to push through on a wait by
> going the next cue in the dominoes before the one before topples;
> QLab just jumps the whole stack of dominoes... We are a rep theatre,
> and every time we changeover we "bang through the show" as quickly
> as possible so we can hear everything, without having to wait for 5
> minute sequences to run in real time. I can't see how to do this in
> QLab without having to scroll back up a bit each time you push GO.
--
Jeremy Lee
Sound Designer, NYC - USA 829
http://www.jjlee.com
Christopher Ashworth
Here's an attempt to make an AppleScript to provide this behavior:
tell application "System Events"
keystroke "v" # the default key command to preview a cue
tell application "QLab"
workspace 1 moveSelectionDown
end tell
end tell
The idea being that this macro would allow you to bang through one cue
at a time, skipping all pre-waits, post-waits, and auto-follows/auto-
continues.
It basically works, except for one odd twist: The keystroke appears to
be sent after the command to move the selection down. The result is
that this will fire the *next* cue in the sequence, and then move
down. I'm not sure why AppleScript is causing the keystroke command
to be delayed until after the moveSelectionDown command. If someone
knows how to fix this, then I think this script serves the requested
purpose.
Best,
Chris
David Bibby
On 8 Sep 2009, at 15:13, Christopher Ashworth wrote:
> Here's an attempt to make an AppleScript to provide this behavior:
>
> tell application "System Events"
> keystroke "v" # the default key command to preview a cue
> tell application "QLab"
> workspace 1 moveSelectionDown
> end tell
> end tell
>
> The idea being that this macro would allow you to bang through one
> cue at a time, skipping all pre-waits, post-waits, and auto-follows/
> auto-continues.
>
> It basically works, except for one odd twist: The keystroke appears
> to be sent after the command to move the selection down. The result
> is that this will fire the *next* cue in the sequence, and then move
> down. I'm not sure why AppleScript is causing the keystroke command
> to be delayed until after the moveSelectionDown command. If someone
> knows how to fix this, then I think this script serves the requested
> purpose.
Can't tell you exactly why it doesn't work, but the following does!
tell application "System Events"
keystroke "v" # the default key command to preview a cue
end tell
tell application "QLab"
workspace 1 moveSelectionDown
end tell
Cheers,
David
David Bibby
I tried it in Script Editor in the following form and it does work,
however, it doesn't as part of a script cue!
tell application "System Events"
tell application "QLab" to activate
keystroke "v" # the default key command to preview a cue
end tell
tell application "QLab"
workspace 1 moveSelectionDown
end tell
Not sure why this would be.... :S
Cheers,
David
On 8 Sep 2009, at 15:13, Christopher Ashworth wrote:
> Here's an attempt to make an AppleScript to provide this behavior:
>
> tell application "System Events"
> keystroke "v" # the default key command to preview a cue
> tell application "QLab"
> workspace 1 moveSelectionDown
> end tell
> end tell
>
> The idea being that this macro would allow you to bang through one
> cue at a time, skipping all pre-waits, post-waits, and auto-follows/
> auto-continues.
>
> It basically works, except for one odd twist: The keystroke appears
> to be sent after the command to move the selection down. The result
> is that this will fire the *next* cue in the sequence, and then move
> down. I'm not sure why AppleScript is causing the keystroke command
> to be delayed until after the moveSelectionDown command. If someone
> knows how to fix this, then I think this script serves the requested
> purpose.
________________________________________________________
Rich Walsh
> tell application "System Events"
> keystroke "v" # the default key command to preview a cue
> tell application "QLab"
> workspace 1 moveSelectionDown
> end tell
> end tell
>
> The idea being that this macro would allow you to bang through one
> cue at a time, skipping all pre-waits, post-waits, and auto-follows/
> auto-continues.
>
> It basically works, except for one odd twist: The keystroke appears
> to be sent after the command to move the selection down. The result
> is that this will fire the *next* cue in the sequence, and then move
> down. I'm not sure why AppleScript is causing the keystroke command
> to be delayed until after the moveSelectionDown command. If someone
> knows how to fix this, then I think this script serves the requested
> purpose.
Is this more elegant?
tell application "System Events"
activate application "QLab"
delay 0.25 -- Wait for Double GO window to open
keystroke "v" -- The default key to preview a cue
keystroke (ASCII character 31) -- Down arrow
end tell
This works from within QLab (say as "Ctrl+V"); I had to add the 0.25s
delay as I think QLab was receiving the trigger and then ignoring the
script keystroke due to the Double GO Protection (possibly?).
Rich
Rich Walsh
>> 1. What is QLab actually doing when it loads media? Adding an audio
>> file seems very slow (compared to SFX), let alone opening a
>> workspace with lots of cues in it.
>
> Well, other than pasting in code I'm not sure the best way to answer
> this question. :) It creates QTMovie objects from each file, for
> one thing.
Would "QLab is converting the files" be a workable explanation as to
why it appears slow, next time someone asks me?
That makes sense now. Can you implement the Q_list parameter for GO in
the same way? Then we can send "GO Q_list 1" and not have to worry
about which cue list is currently being viewed.
>> 3. I don't understand the "Maximum volume of any audio output"
>> setting. What does it do? I'm sure I read this somewhere, but I
>> can't find it now.
>
> With relative fade cues it used to be possible to crank the volume
> on an output up to an arbitrary level. This was bad. The max
> volume will prevent this from happening.
So ostensibly it sets a limit on the the sum of all relative fades?
>> 4. Is there a trick to activating a fader in a Fade Cue without
>> inadvertently moving it? Every time I try to click on one to turn
>> it on I end up changing the level!
>
> No trick currently. Feel free to make a ticket for me to work on
> improving this:
>
> http://tracker.figure53.com/qlab/
Done.
Thanks.
Rich
Rich Walsh
> Rich,
>
> There's a position slider for every series of cues that autofollow.
> So you can start your sequence, listen to it, be happy, then grab
> the slider and advance it to where you want it, and continue from
> there. WAY better than the SFX 5 method, since when you scroll
> around in this way, you're actually completing all of the fades,
> etc. More like fast-forwarding the tape than just moving the
> dominoes closer together.
>
> Try it...
Do you mean in the Active Cues tab? If so, I can see this is very
elegant for certain situations - but it's not as handy as hitting GO,
hovering before the next domino and choosing to flick it early with
another GO. What happens if a scene change goes quicker than normal
and you have to push through a sequence to completion by forcing the
WAITs to complete? I don't want to be fast forwarding tape at this
point!
The script solution works for preshow checks, but what would you do in
a show situation - especially if using a MIDI controller to trigger a
dual-redundant system?
Rich
Christopher Ashworth
> On 8 Sep 2009, at 14:17, Jeremy Lee wrote:
>
>> Rich,
>>
>> There's a position slider for every series of cues that
>> autofollow. So you can start your sequence, listen to it, be
>> happy, then grab the slider and advance it to where you want it,
>> and continue from there. WAY better than the SFX 5 method, since
>> when you scroll around in this way, you're actually completing all
>> of the fades, etc. More like fast-forwarding the tape than just
>> moving the dominoes closer together.
>>
>> Try it...
>
> Do you mean in the Active Cues tab? If so, I can see this is very
> elegant for certain situations - but it's not as handy as hitting
> GO, hovering before the next domino and choosing to flick it early
> with another GO. What happens if a scene change goes quicker than
> normal and you have to push through a sequence to completion by
> forcing the WAITs to complete? I don't want to be fast forwarding
> tape at this point!
>
> The script solution works for preshow checks, but what would you do
> in a show situation - especially if using a MIDI controller to
> trigger a dual-redundant system?
I think I'm not really understanding the goal here. I have not used
SFX (version 5 or 6), so I don't have a point of reference and that
might be the problem.
One thing I can note is that you can always pick any cue and fire it
at any time, i.e. flick the next domino early.
But I don't understand what change in behavior you're asking for in
terms of how the playback position moves down the list. If QLab
doesn't jump the playback position to the start of the next cue
sequence....what's the point in making a cue sequence at all? I'm
confused.
-C
Christopher Ashworth
On Sep 8, 2009, at 1:58 PM, Rich Walsh wrote:
>
> Would "QLab is converting the files" be a workable explanation as to
> why it appears slow, next time someone asks me?
It doesn't convert the files, but it does process them. I'll refer
you to John Siracusa's fantastic review of Snow Leopard for a great
description of one of the limitations of QuickTime 7:
http://arstechnica.com/apple/reviews/2009/08/mac-os-x-10-6.ars/6
(Jump to section "Say what you mean" on that page, although the whole
review is worth reading.)
This isn't to say I can't find some way to speed up media loads, but
it is to say that, with QuickTime, there are sometimes hoops one must
cower before.
> That makes sense now. Can you implement the Q_list parameter for GO
> in the same way? Then we can send "GO Q_list 1" and not have to
> worry about which cue list is currently being viewed.
Well, a cue list in QLab has its own cue number, so just pass in the
Q_number for the list and walla.
>>> 3. I don't understand the "Maximum volume of any audio output"
>>> setting. What does it do? I'm sure I read this somewhere, but I
>>> can't find it now.
>>
>> With relative fade cues it used to be possible to crank the volume
>> on an output up to an arbitrary level. This was bad. The max
>> volume will prevent this from happening.
>
> So ostensibly it sets a limit on the the sum of all relative fades?
Right. Each audio output can go no higher than the limit.
Cheers,
Chris
Rich Walsh
>> Would "QLab is converting the files" be a workable explanation as
>> to why it appears slow, next time someone asks me?
>
> It doesn't convert the files, but it does process them. I'll refer
> you to John Siracusa's fantastic review of Snow Leopard for a great
> description of one of the limitations of QuickTime 7:
>
> http://arstechnica.com/apple/reviews/2009/08/mac-os-x-10-6.ars/6
Very useful link, thank you: "It's a feature of QuickTime" will be my
answer.
>> That makes sense now. Can you implement the Q_list parameter for GO
>> in the same way? Then we can send "GO Q_list 1" and not have to
>> worry about which cue list is currently being viewed.
>
> Well, a cue list in QLab has its own cue number, so just pass in the
> Q_number for the list and walla.
That's very clever: hadn't thought of that. Of course you need the
different behaviour for STANDBY_+ as it doesn't recognise Q_number.
Rich
Rich Walsh
> I think I'm not really understanding the goal here. I have not used
> SFX (version 5 or 6), so I don't have a point of reference and that
> might be the problem.
>
> One thing I can note is that you can always pick any cue and fire it
> at any time, i.e. flick the next domino early.
>
> But I don't understand what change in behavior you're asking for in
> terms of how the playback position moves down the list. If QLab
> doesn't jump the playback position to the start of the next cue
> sequence....what's the point in making a cue sequence at all? I'm
> confused.
Let me try to explain... We've all spent the last 7 years in this
paradigm for a scene change:
Q1: Play wind
WAIT 0s
Fade wind in
WAIT 1s
Play dog bark
WAIT 2s
Play door bell
WAIT 3s
Play thunder
Q2: Fade wind out
You go Q1 and the cursor jumps down to the WAIT 1s, waits there for
1s, jumps down to WAIT 2s, waits there for 2s, jumps down to WAIT 3s,
waits there for 3s and _only then_ jumps down to Q2. If you push go
the highlighted cue will fire, essentially crashing the wait as I've
tried to describe.
Now, most of the time this is fine, as you don't need to be stood by
for Q2 until Q1 has completed. On those occasions where you do, you
just add "Goto Q2" (and a WAIT 0s) after the first WAIT 0s. This gives
me complete control of when the operator can crash a sequence (NB:
_without using the keyboard_: they only have a MIDI button), and when
they can't.
What's more, since we like to run through the entire show on a
changeover day (to look for any surprises, remind ourselves of what
show it is, _and_ check that both machines stay in sync), we can speed
through it without hanging around for all those waits to complete.
There are downsides to this - load to time gets a bit tricky, for
example - but what I'm asking for is an option to have the "standby
cursor" follow the progress of the dominoes as above, and leave it up
to me when I want to make it jump ahead with a Goto Cue.
Does that help?
Rich
Charlie Richmond
Surely you have been able to do this about 3 dozen different ways using ShowMan,
though?
C-)
Christopher Ashworth
you meant.
As a general modification to the overall way the cue selection travels
down the workspace I don't think this behavior translates well into
QLab. It's pretty clear if you have a single linear progression down
the list, but QLab workspaces often do not have a single linear
progression down the list. Using Group Cues can (and often does)
create trees of dominoes, rather than just lines of dominoes. And
those trees might be self-referential, creating loops. I suppose we
can ignore branches in the cue sequence, but then that means you get
to pound through *some* of your cues but not others, and it's not
immediately clear why QLab is only letting you touch some of them.
However, there is actually a way to get the behavior you describe for
the cases where it makes sense. What you do is give your cue list a
number, and then instead of using auto-continues or auto-follows for
the entire sequence, you can use Start Cues (that target the cue list)
as an alternate form of auto-continue.
For example:
CUE LIST A "main cue list"
AUDIO CUE 1 "play wind" (auto-continue)
START CUE 2 targets CUE LIST A, with pre-wait of 1 second
AUDIO CUE 3 "play dog bark" (auto-continue)
START CUE 4 targets CUE LIST A, with pre-wait of 2 seconds
AUDIO CUE 5 "play door bell"
This construction creates the equivalent of what you describe below.
(Well, the first part of it, anyway.) It creates a cue sequence where
the selected cue jumps from Audio Cue 1, to Audio Cue 3, to Audio Cue
5, allowing your operator to "crash" ahead early on those cues if they
want. But if the operator just wants to let the sequence play in the
normal order the start cues will automate the process.
One thing to note is that it might sometimes be necessary to add Stop
Cues to kill off the previous Start Cues, so they don't re-start a cue
that your operator crashed through. This would only be necessary if
the pre-wait was a long time and the audio cue in question might
finish before the start cue finally fires.
-C
Rich Walsh
> As a general modification to the overall way the cue selection
> travels down the workspace I don't think this behavior translates
> well into QLab. It's pretty clear if you have a single linear
> progression down the list, but QLab workspaces often do not have a
> single linear progression down the list. Using Group Cues can (and
> often does) create trees of dominoes, rather than just lines of
> dominoes. And those trees might be self-referential, creating
> loops. I suppose we can ignore branches in the cue sequence, but
> then that means you get to pound through *some* of your cues but not
> others, and it's not immediately clear why QLab is only letting you
> touch some of them
I don't think that there is anything inherently less "linear" in QLab
than any other show control package we've been using - particularly
ShowMan as Charlie pointed out.
Regardless of what is looping around, firing, jumping, and so on, the
progression of the "cue that will fire when you press GO" is "linear"
- in that (except for some extremely specialised circumstances) it is
predictable, and does progress down the list. Until I looked at this
issue the other day, I expected that using a Group Cue would allow you
to choose to zip up a line of dominoes out of the way (as it does);
what I hadn't anticipated is that QLab's intelligence effectively does
the same thing for _any_ sequence by jumping the "standby" around the
follow-ons.
If my understanding had been correct, then this behaviour would have
given me a conscious choice as to whether a line of dominoes is
crashable or not - a paradigm I've lived in for some time with no
frustration about it. Still, not to worry - we have a couple of
workarounds to be getting on with while we settle in round here!
> However, there is actually a way to get the behavior you describe
> for the cases where it makes sense. What you do is give your cue
> list a number, and then instead of using auto-continues or auto-
> follows for the entire sequence, you can use Start Cues (that target
> the cue list) as an alternate form of auto-continue.
>
> For example:
>
> CUE LIST A "main cue list"
> AUDIO CUE 1 "play wind" (auto-continue)
> START CUE 2 targets CUE LIST A, with pre-wait of 1 second
> AUDIO CUE 3 "play dog bark" (auto-continue)
> START CUE 4 targets CUE LIST A, with pre-wait of 2 seconds
> AUDIO CUE 5 "play door bell"
OK, that's relatively elegant. Here is a script should one ever need
to do it (with a nod to Mark & Lard for those of you listening to
Radio 1 back in the day)...
tell application "QLab"
set theCueList to current cue list of workspace 1
set originalCue to last item of (selected of workspace 1 as list)
set continue mode of originalCue to auto_continue
tell workspace 1
make type "Start"
set newStartCue to last item of (selected as list)
set cue target of newStartCue to theCueList
set pre wait of newStartCue to 5
set q name of newStartCue to " stop..."
make type "Stop"
set newStopCue to last item of (selected as list)
set cue target of newStopCue to newStartCue
set q name of newStopCue to " ...carry on"
set continue mode of newStopCue to auto_continue
end tell
end tell
I've added a Stop Cue that will stop the Start Cue if you choose to
crash ahead. Presumably the danger is that if the Audio Cue is shorter
than the remaining time of the pre wait on the Start Cue, then when
the Start Cue completes it will fire the Audio Cue again, right?
We'll file all that under "just in case" and see how we get on without
it! It is rather, erm, ugly...
Christopher Ashworth
> On 10 Sep 2009, at 15:08, Christopher Ashworth wrote:
>
>> As a general modification to the overall way the cue selection
>> travels down the workspace I don't think this behavior translates
>> well into QLab. It's pretty clear if you have a single linear
>> progression down the list, but QLab workspaces often do not have a
>> single linear progression down the list. Using Group Cues can (and
>> often does) create trees of dominoes, rather than just lines of
>> dominoes. And those trees might be self-referential, creating
>> loops. I suppose we can ignore branches in the cue sequence, but
>> then that means you get to pound through *some* of your cues but
>> not others, and it's not immediately clear why QLab is only letting
>> you touch some of them
>
> I don't think that there is anything inherently less "linear" in
> QLab than any other show control package we've been using -
> particularly ShowMan as Charlie pointed out.
>
> Regardless of what is looping around, firing, jumping, and so on,
> the progression of the "cue that will fire when you press GO" is
> "linear" - in that (except for some extremely specialised
> circumstances) it is predictable, and does progress down the list.
There's an important difference between the path of the playback
position and the path of the cue sequences. I have no idea whatever
how ShowMan or SFX treat these two things, but with QLab the path of
the playback position is indeed linear and the path of the dominoes is
indeed often non-linear, i.e. branching.
So it's true that the selection/playback position does have a
predictable linear path down the list.
But, and here's the key: QLab's current linear path for the playback
position is fundamentally different from the linear path you
described. In other words, if I added an "SFX 5" mode for going down
the cue list, it would instantly and necessarily define a new and
different linear path through the cues. Not in all cases, certainly,
but in many (normal) cases.
For example:
Let's say we have two group cues that are in "fire first child and go
to next cue" mode.
GROUP A
CUE 1 (auto-continue)
CUE 2 (auto-continue)
CUE 3
GROUP B
CUE 4 (auto-continue)
CUE 5 (auto-continue)
CUE 6
Now, the way QLab works now, this is basically two series of dominoes
starting out at GROUP A and GROUP B. It is the intent of the
designer, in this case, to have two sequences that can overlap. They
are entirely independent. One night they might fire in this order:
1,2,3,4,5,6
Another night they might fire in this order:
1,4,2,5,3,6
Or indeed, any overall order where the ordering of the separate sub-
sequences is maintained.
Now, we flip the switch and enter into this new playback mode. The
operator fires GROUP A, and...we need a rule for where the selections
goes next. Cue 2? Group B? Under the original design either one
might fire next. Under the new scheme perhaps we require the
selection to go to each cue in each sequence, so the selection goes to
Cue 2. But now we can only ever create the following order:
1,2,3,4,5,6
That's a valid (and linear) choice for the path of the playback
position, but it's a now a different design.
-C
Rich Walsh
To me it appears entirely logical that after you GO Group A you are
stood by for Group B; that would be exactly what I would want to
happen. My minor little whining is about this situation:
CUE 1 (auto-continue)
CUE 2 (auto-continue)
CUE 3
CUE 4 (auto-continue)
CUE 5 (auto-continue)
CUE 6
In this case QLab stands you by for Cue 4 as soon as you GO Cue 1. I
would rather that it stood by Cue 2, and then went anyway when the
timer said so, and so on (sorry to repeat myself again). Then, if I
want the QLab behaviour I can either turn them into Group Cues, as
above, or do this:
CUE 1 (auto-continue 0s)
Goto CUE 4 (auto-continue)
CUE 2 (auto-continue)
CUE 3
CUE 4 (auto-continue)
CUE 5 (auto-continue)
CUE 6
Now I have more choices when programming, and, what's more, a new
option when running the show: make a sequence run faster (if the
designer has chosen to not put the sequence in a Group Cue). The two
variations you describe above are still available to me if I choose to
program in the appropriate way.
The preference could be called "When advancing the playback position,
skip over cues that will automatically follow-on", with the default of
"on" representing the current behaviour. I think that would be
entirely consistent with the way the Group Cue modes work - but I
won't be surprised if I've missed something and got that wrong too!
Please don't misinterpret this discussion as criticism of the design,
by the way. Imagine what it would be like if you could actually talk
to the person who writes Pro Tools - or the Mac OS for that matter!
Thanks.
Rich
Christopher Ashworth
I'm gonna reply in reverse order:
> Please don't misinterpret this discussion as criticism of the
> design, by the way.
Well, even if it were that wouldn't be a bad thing. Plenty of
critiques in the past have led to improvements. I'm personally quite
enjoying this exchange, since it, as Richard said, has got me thinking.
> Then, if I want the QLab behaviour I can either turn them into Group
> Cues, as above, or do this:
>
> CUE 1 (auto-continue 0s)
> Goto CUE 4 (auto-continue)
> CUE 2 (auto-continue)
> CUE 3
> CUE 4 (auto-continue)
> CUE 5 (auto-continue)
> CUE 6
Sidenote: I believe the above cue sequence represents a slight
misunderstanding of the Goto Cue. The Goto Cue will send both the
playback position and the cue sequence to cue 4, which means cues 2
and 3 would never play.
And finally, getting back to the meat of the matter:
> To me it appears entirely logical that after you GO Group A you are
> stood by for Group B; that would be exactly what I would want to
> happen. My minor little whining is about this situation:
>
> CUE 1 (auto-continue)
> CUE 2 (auto-continue)
> CUE 3
> CUE 4 (auto-continue)
> CUE 5 (auto-continue)
> CUE 6
>
> In this case QLab stands you by for Cue 4 as soon as you GO Cue 1. I
> would rather that it stood by Cue 2, and then went anyway when the
> timer said so, and so on (sorry to repeat myself again).
I guess what you're describing here is a mode in which the selection
travels incrementally down the "trunk" of the cues, ignoring all
branches. Specifically, whenever a separate cue sequence was created
by a Start Cue or a Group Cue in "fire first and move to next" mode,
that separate sequence must always play out in normal time and would
not be "crashable" by the operator. The only "crashable" cues would
be the ones on the main path, not the branching paths.
That does sound like a possibility, although I still have
reservations. For example, you say above that this behavior feels
entirely logical to you, but would that be true for others as well?
If I change the mode on a group cue to "fire first and enter into
group" then the sequence wouldn't branch and my operator will be
allowed to crash cues inside the group. Is it confusing that the cues
inside some groups are crashable and others are not?
Another (perhaps more important) reservation is about the demand for
the feature relative to the additional complexity. Although many QLab
users also have an SFX background, this is the first time the issue
has come up. That suggests to me that in practice this doesn't come
up as a particularly pressing issue. As Richard said, one can always
split a sequence into two sequences if there's any chance that the
timing of the GOs needs to be variable. And if it's *really* crucial
to have a set delay that can also be crashed if necessary, well, there
is always the Start Cue technique. So the crucial cases are covered.
Are the other cases pressing enough to make the change?
Hmmmm....interesting.
Best,
Chris
Christopher Ashworth
and I didn't notice it.
I see that [QLab] tag in the subject and I just assume it's on list.
Sorry!
On Sep 11, 2009, at 8:09 AM, Christopher Ashworth wrote:
>
> Well, even if it were that wouldn't be a bad thing. Plenty of
> critiques in the past have led to improvements. I'm personally quite
> enjoying this exchange, since it, as Richard said, has got me
> thinking.
[...snip...]
> As Richard said, one can always split a sequence into two sequences
> if there's any chance that the timing of the GOs needs to be variable.
________________________________________________________
Matt Otto
sam kusnetz
first of all, thank you rich for this fascinating discussion.
regardless of all of our opinions on the question of where the
playback/standby position belongs during a series of auto-continues, i
think this is a really useful and interesting conversation to have.
> CUE 1 (auto-continue)
> CUE 2 (auto-continue)
> CUE 3
> CUE 4 (auto-continue)
> CUE 5 (auto-continue)
> CUE 6
>
> In this case QLab stands you by for Cue 4 as soon as you GO Cue 1. I
> would rather that it stood by Cue 2, and then went anyway when the
> timer said so, and so on (sorry to repeat myself again). Then, if I
> want the QLab behaviour I can either turn them into Group Cues
it's funny... when i first started using qlab (in... 2005!?) one of
the first things i noticed was this behavior wherein taking cue 1
stands me by for cue 4. and i was thrilled, because i have always
wondered why the f*** SFX thought it was a good idea to allow the
operator to screw up a series of autofollows by taking an early cue.
in fact, i think that this behavior is one of the fundamental
differences between SFX and qlab, and one of the fundamental
advantages of qlab. this behavior prevents a trigger-happy operator or
a scattered stage manager from ruining sequences of cues by calling or
taking a cue out of order.
i was working on a show, programmed in SFX, which was immensely
complicated and had cue sequences with dozens of waits. the stage
manager had no knowledge of how the show was programmed, she just knew
what cues to call and why. there were numerous occasions in which the
timing of the business onstage would work out differently and she
would call a cue before the previous sequence had all played out. my
only option at that point was to deliberately wait until i saw the
sequence finish, and then take the called cue late. this, naturally,
irritated me considerably.
> Now I have more choices when programming, and, what's more, a new
> option when running the show: make a sequence run faster (if the
> designer has chosen to not put the sequence in a Group Cue).
i don't think, personally, that it's ever valid to have options when
running the show. the entire purpose of computerizing sound playback
it to eliminate such vagaries and prevent the sound operator's opinion
and timing from accidentally altering the sound designer's intention.
i guess the real thing is, other than a deliberately accelerated
rehearsal, i can't think of a scenario in which the SFX-type behavior
is useful. and i can think of plenty of situations in which it's
problematic. if you want the operator/stage manager to be able to
respond to events on stage in a different manner from night to night,
then the relevant cues shouldn't be auto-continued at all. and if you
want the cues to happen the exact same way every night, then use the
auto-continue.
cheerio
sam
--
there can be hours between the so and the what of the so
http://www.notquite.net
Richard B. Ingraham
> -----Original Message-----
> From: qlab-b...@lists.figure53.com [mailto:qlab-
> bou...@lists.figure53.com] On Behalf Of Matt Otto
> Sent: Friday, September 11, 2009 11:43 AM
> To: Discussion and support for QLab users.
> Subject: Re: [QLab] Back To Dumb Questions - Dominoes
>
> I generally switch from QLab to SFX and the reason that this is not an
> issue is because when running the show the operator does not need to
> know or follow the cursor down a complicated sequence. All the operator
> needs to do is stand by for the next cue especially if the next cue
> needs to fire before the pervious sequence ends. Whats great about QLab
> is that it will do this automagically where in SFX you have to set up a
> GoTo command adding complexity to the cue sequence which is probably
> already complicated enough.Besides if you do need to crash through a
> sequence you can fire the sequence and then highlight the cue you want
> to crash into and it will fire when you press the GO button.
I just want to be clear on this. The behavior Rich is asking about is
behavior from SFX 5.x This was a product developed over 13 or years ago or
so, and has not been a current product for almost 2 years. SFX 6.x behaves
in the same way that QLab does. To be more precise, in SFX 6 once you link
a series of cues together SFX will treat that as a single sequence and
deliver sample accurate timing on that linked sequence. That was the main
reason we went that route. Also we had many requests over the years for SFX
to work in the manner it does now and the direction Chris has taken with
QLab. (yes, even before QLab hit the scene from the best of my
knowledge/memory)
As I said to Chris in the, now public, private email (LOL) this is a catch
22 situation. No matter which method you choose there will be some people
who are really happy and others that wished it worked the other way. There
are many of these and I'm sure more will continue to pop up as time goes on.
:-)
But I just want to make sure it's clear that in SFX 6, you don't need to add
a bunch of Goto Cues (or whatever the proper equivalent is in QLab, sorry...
I've only used it a couple of times) to jump to the next sequence of linked
cues.
I personally like this behavior a lot better. But as this thread proves,
not everyone will agree and Rich has valid points, as usual.
Thanks,
Richard B. Ingraham
RBI Computers and Audio
http://www.rbicompaudio.20m.com
Matt Otto
Richard B. Ingraham
> From: Christopher Ashworth [mailto:ch...@figure53.com]
> Sent: Friday, September 11, 2009 8:11 AM
> To: Discussion and support for QLab users.
> Cc: Richard Ingraham
> Subject: Re: [QLab] Back To Dumb Questions - Dominoes
>
> and I didn't notice it.
>
> I see that [QLab] tag in the subject and I just assume it's on list.
> Sorry!
>
No worries. I only replied off list because I felt much of what I was
talking about would be of little interest to the QLab list. :-)
But the synopsis was essentially that SFX 6 (as opposed to SFX 5.x) works in
the same manner that QLab does. And then I attempted to explain why that
choice was made, at least from our end.
Rich Walsh
some work yesterday and didn't have time to respond. I have no idea
how Chris manages!
On 11 Sep 2009, at 13:09, Christopher Ashworth wrote:
>> Then, if I want the QLab behaviour I can either turn them into
>> Group Cues, as above, or do this:
>>
>> CUE 1 (auto-continue 0s)
>> Goto CUE 4 (auto-continue)
>> CUE 2 (auto-continue)
>> CUE 3
>> CUE 4 (auto-continue)
>> CUE 5 (auto-continue)
>> CUE 6
>
> Sidenote: I believe the above cue sequence represents a slight
> misunderstanding of the Goto Cue. The Goto Cue will send both the
> playback position and the cue sequence to cue 4, which means cues 2
> and 3 would never play.
That's interesting. It also seems to play Cue 4 if Cue 1 auto-
continues. Is there a way if navigating the cue list this way (without
cheating and using a script)? I suppose if you do want to skip a chunk
of cues (say you're trying out the show without them) you can either
disarm them, or skip round them by using a Goto to a Memo - or take
the auto-continue off the cue before the Goto, I guess.
I have to say, I do like the fact that I can remove a follow-on
without losing its duration!
Again, that's logical as these are cues that aren't follow-ons. At
present I can see no way in which an operator can tell if a Group Cue
is going to expand or not - without looking at the programming of
course - so I don't think this would be any more confusing (just
confusing in a different way).
> Another (perhaps more important) reservation is about the demand for
> the feature relative to the additional complexity. Although many
> QLab users also have an SFX background, this is the first time the
> issue has come up. That suggests to me that in practice this
> doesn't come up as a particularly pressing issue. As Richard said,
> one can always split a sequence into two sequences if there's any
> chance that the timing of the GOs needs to be variable. And if it's
> *really* crucial to have a set delay that can also be crashed if
> necessary, well, there is always the Start Cue technique. So the
> crucial cases are covered. Are the other cases pressing enough to
> make the change?
I am not talking about situations where you are reacting to a cue-able
event, and therefore should be using two cues (ie: if something has to
happen in response to something on stage then make it a cue). I am
talking about these 3 situations:
1. Twice a week we changeover between shows and have gotten into the
habit of banging through the cues quickly like this to check the show.
This also checks our two dual redundant machines, which rely on MIDI
triggering to work, so any advancing of the cuelist can not be done
with keyboard and mouse. We would have to program every single non-
zero follow-on with the Start Cue technique if we wish to continue
this behaviour. I guess we'll have to cope - although I will add the
"preview and step forward" script to a MIDI trigger so we can choose
to step through any really long sequences faster than realtime.
2. Whenever I am running a sequence as a designer I have found it very
useful to be able to jump ahead in this way without stopping, changing
the timing and running the sequence again. It is hard to judge, but
used as I am to this paradigm, I probably go early on a WAIT at least
10 times a day when I am programming. I suppose I can use a script to
make using Start Cues the non-zero follow-ons that I anticipate I will
want to crash, and then go back and retrofit normal programming later
(I'm sure this would break my addiction to working in the "SFX 5 way"
quite quickly!).
3. Very occasionally, particularly in a show that has been repping for
a few months, a scene change (or something) can go unexpectedly
quickly and an operator can crash through a few follow-ons to avoid a
car crash. If this happens consistently, the programming can be
tweaked. If an operator is on the ball, they will know how to get
ahead without disturbing the overall flow of things if, say, an actor
jumps a few lines while a sequence is chugging along underneath them.
If you know in advance that things may get horribly out of sync you
can of course make your follow-ons into cued events, but see 2. above.
--
On 11 Sep 2009, at 16:43, Matt Otto wrote:
> I generally switch from QLab to SFX and the reason that this is not
> an issue is because when running the show the operator does not need
> to know or follow the cursor down a complicated sequence. All the
> operator needs to do is stand by for the next cue especially if the
> next cue needs to fire before the pervious sequence ends. Whats
> great about QLab is that it will do this automagically where in SFX
> you have to set up a GoTo command adding complexity to the cue
> sequence which is probably already complicated enough.Besides if you
> do need to crash through a sequence you can fire the sequence and
> then highlight the cue you want to crash into and it will fire when
> you press the GO button.
I have the opposite view, after a few years operating other people's
shows - and talking to my operators. I _like_ to see the cue
progressing so I know what is going on; I only want to be jumped ahead
when I need to be standing by on the next cue whilst a sequence is
still running. A couple of designers I work with program just triggers
in the "main cue list", with all the business going on in other lists
you can't see (a tiny bit like the old sequencer/sampler combination).
This has some tremendous advantages, particularly for shows that are
developed in rehearsals and changing all the time, and also for being
able to stop, say, a wrongly-triggered voiceover without panicking all
the backgrounds. Sat behind such a show, however, I had absolutely no
idea what any of the cues actually did; this made me very
uncomfortable (and certainly didn't empower me to operate well - as
opposed to pushing the green button when the green light came on and
hoping for the best).
Is now a good time to point out that what I'm doing here is trying to
detect elephant traps before we make QLab available in the list of
options for designers in our multi-venue producing rep house? We are
going to do it, but I like to be prepared and aim to smooth the
transition as best I can. We have 15-20 full-time professional sound
operators, some of whom design as well; I'm not worrying about Stage
Managers here. Every show is taught on to at least one other person
who didn't watch it being programmed in the tech - and this is done in
a very short space of time, mostly during actual performances. That's
not meant to be belittling at all, I'm just trying to convey that I
don't feel a need to protect the show from the operator in our
circumstances.
Anyway, I guess we can make a cue go early by scrolling back up to it
one line at a time (remember this all has to be done via MIDI commands
to keep our dual systems in sync).
If you're interested, we aim to be able to supply and support SFX 5,
SFX 6, ShowMan, SAM, G-Type & QLab - until a significant number of
designers start asking for something else as well; this is how we
ended up with SFX, and this is why we're getting QLab.
--
On 11 Sep 2009, at 17:11, sam kusnetz wrote:
> it's funny... when i first started using qlab (in... 2005!?) one of
> the first things i noticed was this behavior wherein taking cue 1
> stands me by for cue 4. and i was thrilled, because i have always
> wondered why the f*** SFX thought it was a good idea to allow the
> operator to screw up a series of autofollows by taking an early cue.
>
> in fact, i think that this behavior is one of the fundamental
> differences between SFX and qlab, and one of the fundamental
> advantages of qlab. this behavior prevents a trigger-happy operator
> or a scattered stage manager from ruining sequences of cues by
> calling or taking a cue out of order.
I'm sorry this will sound a bit patronising and arrogant, but see
above for what I consider is the higher calibre of the operators I
work with than your examples. I can see the advantages for less
capable operators, but perversely our highly-skilled operators expect
to see the cogs turning beneath a show - and grab hold of them if
needs be to keep the show as close to what the designer intended each
night.
> i was working on a show, programmed in SFX, which was immensely
> complicated and had cue sequences with dozens of waits. the stage
> manager had no knowledge of how the show was programmed, she just
> knew what cues to call and why. there were numerous occasions in
> which the timing of the business onstage would work out differently
> and she would call a cue before the previous sequence had all played
> out. my only option at that point was to deliberately wait until i
> saw the sequence finish, and then take the called cue late. this,
> naturally, irritated me considerably.
These are the circumstances in which you can crash ahead to make
something work and then go back and correct your programming to give
it more flexibility to respond to the unpredictable. I have a set of
tools to make this possible now, but they are workarounds. An option
to override the behaviour would be nice, but if I'm alone in thinking
that then I'll learn to adapt.
>> Now I have more choices when programming, and, what's more, a new
>> option when running the show: make a sequence run faster (if the
>> designer has chosen to not put the sequence in a Group Cue).
>
> i don't think, personally, that it's ever valid to have options when
> running the show. the entire purpose of computerizing sound playback
> it to eliminate such vagaries and prevent the sound operator's
> opinion and timing from accidentally altering the sound designer's
> intention.
That wasn't as clear as I meant, sorry. As the designer I can _choose_
to give the operators options to deal with the vagaries of live
theatre, such as needing to make something go quicker in an emergency
without having to make it into individual cues that have to be taken
every single night. The great Paul Groothuis taught me to appreciate
that the single most useful (and the most potentially damaging)
resource I have at my disposal as a designer _is_ the operator: if
they aren't there to use their opinion and timing to make the show as
good as it can be every night you might as well not bother with an
operator. Obviously this only apples when I have the luxury of an
experienced operator with whom I can have a dialogue so that they
understand my intention: that's the real trick of design I think. When
I work for other companies I have to do things differently, of course.
> i guess the real thing is, other than a deliberately accelerated
> rehearsal, i can't think of a scenario in which the SFX-type
> behavior is useful. and i can think of plenty of situations in which
> it's problematic. if you want the operator/stage manager to be able
> to respond to events on stage in a different manner from night to
> night, then the relevant cues shouldn't be auto-continued at all.
> and if you want the cues to happen the exact same way every night,
> then use the auto-continue.
As I said above, the most useful time for this behaviour is exactly
when you are establishing which cues can and can't follow on. I have
found that the times when we have had to scroll down to get to the
right cue come up rarely (and are almost always fixed during
previews), whilst I fear that the times when I will need to scroll up
in this new world will arise frequently (particularly during the tech
sessions before previews!).
--
Finally, an important observation for Chris about what I believe to be
how the behaviour of SFX 6 differs quite significantly here: if you
start a sequence of cues halfway-through, it automatically locates all
the cues that would be running if you had started from the beginning
to the correct time and _plays them as well_. When I have a chance to
turn my attention to SFX 6 to prepare for making that available too
I'll find out if this issue has been addressed yet...
Is anyone else a bit tired of this thread now? I feel like a right
pompous whinger...
Rich
Christopher Ashworth
> Is anyone else a bit tired of this thread now? I feel like a right
> pompous whinger...
I'm not tired of it at all, I'm finding it tremendously informative
and interesting. Thank you for taking the time to make such a
detailed case for this feature.
The possibility of providing this behavior as an optional mode is now,
shall I say, much more conceivable to me. There are real issues of
implementation to consider, and consequences to evaluate, but you do
have me thinking seriously about it.
Best,
Chris
Matt Otto
Christopher Ashworth
> trouble shooting it over the phenol.
I'd say the first step is to figure out how all that phenol got there
in the first place. I've found that stuff is generally bad for the
operator.
Matt Otto
Juniper Shuey
got me thinking about an issue in my last show.
I love the "load to" feature so that I can get through a series of
cues that are all linked and start at the end of track that is about
to fade into another track. In a work that we are working on right
now i have sound cues that are ten minutes and timed out based on the
sound files and automatically fade using pre-waits. I also have a two
other computers running video sequences that are timed out as well
with prewaits and fades and autocontinues and groups used for visual
clarification. here is an example of a linked set of cues that last
for about three minutes:
Fade IN light on Shannon 00:00.000 00:05.000 00:00.000 auto-continue
Shannon_Shaking_OPening.png 00:00.000 00:00.000 00:00.000 auto-
continue
Fade OUT shannon light 00:10.000 00:05.000 00:05.000 auto-follow
Fade IN reflected video in mirrors 00:02.000 00:05.000 00:00.000
auto-continue
Video on Floor reflected in Mirrors 00:00.000 00:30.767 00:00.000
auto-continue
Fade OUT reflected Video 00:25.000 00:05.000 00:05.000 auto-follow
Fade IN Sky with distortion and Ticking 00:15.000 00:00.000
00:00.000 auto-continue
Fade IN sky 00:00.000 00:07.000 00:00.000 auto-continue
Sky 00:00.000 00:00.000 00:00.000 auto-continue
Fade OUT Sky 00:20.000 00:05.000 00:00.000
What would be great was if you could fast forward this whole series
with a slider much like the "load to" feature but you could do it once
this series of cues was already playing. Thus being able to hurry
transition to transition.
I know that you can do some of this with the active cues slider but
what that doesn't let you do is fast forward the video cue and the
fade cue at the same time and since both are playing that the same
time it means that you can either fast forward the fade cue to get
past it's prewait or you have to fastforward the the video cue and
guess the approximate time of and then fast forward the fade cue.
These options don't give you an idea of the actual transition since it
is at a different time in the sound or video files in play.
I hope this makes sense. It seems like it is in line with this topic
and wonder if it would be a solution?
BJ Oliver
bjoliver