BACK or UNDO button?

[Alex]

Hi All,

In searching the forum and scouring the manual, I haven't seen an
elegant way to go "BACK" similar to how a lighting console's BACK
button behaves. I though that Command-Z might reverse a GO push, but
that only undoes operations done to cues.

If an operator fires a cue prematurely, I've just had to have them
STOP ALL and then fire the correct cue. Not a good way, as it will
lose all the content that is up.

I'd like to be able to crossfade back into the previous cue and have
the next cue loaded and ready to re-fire.

Any suggestions?

Alex Amyot
Technical Director
Dept. of Speech, Theatre and Dance
The University of Tampa

[Zach Rosing]

Dear God of QLab, please PLEASE find some way to implement this. I
know when you're dealing with video and sound this is probably hugely
challenging, but it's a large source of my stress when people other
than me are running a show.

[dan howarth]

try hotkey "S" to stop the highlighted file -- ie, teach the operator to 

keep a hands-on approach, no mouse. arrow keys to navigate, "L" to reload. etc etc etc. 

there's nothing like a mis-cue !! cheers !! peace d

--
Change your preferences or unsubscribe here:
http://groups.google.com/group/qlab

Follow Figure 53 on Twitter: http://twitter.com/Figure53

--
dh

[sam kusnetz]

Alex wrote:

In searching the forum and scouring the manual, I haven't seen an
elegant way to go "BACK" similar to how a lighting console's BACK
button behaves. 

the reason that there really cannot be any such thing as a back button in sound (not just qlab) is because there is no obvious way to standardize what it would do. consider the following situations:

1. there is one sound playing. the next cue starts a new sound playing and simultaneously fades out the first sound. if I take that cue, then press back, what should happen? should the new sound fade out? should the old sound start again from the beginning, or from where it left off? would it fade in?

2. there are six sounds playing through six different speakers. the next cue is a sequence of complex fades which bring the various sounds up and down in various speakers, and then the sequence of fades concludes with the sounds restored to playing in the original six speakers. if I hit the back button, should the sequence of fades be carried out again but in reverse?

3. a cue sends a string of midi commands to an external processor. how could the back button know what commands to send to restore the previous settings on the processor?

those are just three that I came up with off the top of my head. there are many others.

fundamentally, a lighting board executing a cue is a much simpler concept, because each cue on a lighting board represents the total state of the lighting system (by and large. i know that there are exceptions to this). on a sound system, each individual cue contains a very limited set of information, and has no information about the rest of the sound system. and since cues can be executed at arbitrary times, there is no way for cues to contain such information. if there is a piece of music playing, and then the next cue is a doorbell which is taken off of a visual cue that happens at a different point during each performance, then how can the doorbell cue "know" about the state of music cue?

If an operator fires a cue prematurely, I've just had to have them
STOP ALL and then fire the correct cue. Not a good way, as it will
lose all the content that is up.

instead, have the operator select the cue that you want stopped, and press 'S' on the keyboard. that will stop only the selected cue. then you can restart the previous cue by hand.

cheerio

sam
--

sam kusnetz

503.201.2591

s...@notquite.net

[Willo]

It's handy to use the 'pause' and 'continue' features (hitting the
[ or ] keys to the right of the letter P key), but they operate
globally on all existing cues. (It's better than hitting ESC and
losing any loaded progress, but still not always appropriate in all
situations)

I'd like to see a 'pause most recent cue' function (perhaps the letter
P itself?) which only halts the most recent sequence, and allows
currently playing cues to continue.

Craig

On Dec 16, 5:57 am, Alex <aam...@gmail.com> wrote:
> Hi All,
>

> If an operator fires a cue prematurely, I've just had to have them
> STOP ALL and then fire the correct cue. Not a good way, as it will
> lose all the content that is up.
>
> I'd like to be able to crossfade back into the previous cue and have
> the next cue loaded and ready to re-fire.
>
>

> Alex Amyot

[Rich Walsh]

On 16 Dec 2011, at 05:32, Willo wrote:

> I'd like to see a 'pause most recent cue' function (perhaps the letter
> P itself?) which only halts the most recent sequence, and allows
> currently playing cues to continue.

Well, the beauty of QLab is that you can make one yourself:

tell front workspace
try
set previousCue to item -2 of (active cues as list)
set parentCue to parent of previousCue
if mode of parentCue is not cue_list then
pause parentCue
else
pause previousCue
end if
end try
end tell

What's more, you can then adjust it if your concept of "sequence" is different from anyone else's (a Group Cue, in my case).

You have to wonder what pyro operators do if they go early on a cue - or maybe they just take a little more care before pressing GO?

Rich