Breaking out of a song list gracefully

[Golla]

Hi all,

Long time reader, first time poster...blah blah blah. I'm trying to
figure out how to do something, and all my solutions this far have
been inelegant. Hoping someone smarter than I can find a simple
solution. Here's the scenario:

I've got a group of songs for preshow music (all on auto-follow),
let's say it looks like this:
Song 1
Song 2
Song 3
Song 4
Song 5
etc.

And then I've got another song which is the song I want to lead into
the show. Let's call it Song N.

Given that our preshow can be unpredictable in length, I'm looking for
a way of making Song N the next song to play at any point in the
preshow group. For example, let's say Song 4 is playing, and we're
ready for places. I'd like to execute something that makes Song N the
next song to play *when Song 4 is done.* That's the part I'm having
trouble with. I don't want to fade Song 4 (or whichever) out in the
middle of it and fade in Song N. I want the music to continue pretty
much seamlessly, just breaking out of the preshow list and making Song
N the next to go when the current song is finished.

The best solution I've come up with so far is to have a disarmed GOTO
cue (with auto-follow) in between each song, thusly:
Song 1
Disarmed GOTO to Song N
Song 2
Disarmed GOTO to Song N
Song 3
etc.

...with a cue to arm all of the gotos when we're at places. It works,
but it's rather inelegant. Better ideas?

Andrew

[Rich Walsh]

On 26 Feb 2012, at 01:44, Golla wrote:

> The best solution I've come up with so far is to have a disarmed GOTO
> cue (with auto-follow) in between each song, thusly:
> Song 1
> Disarmed GOTO to Song N
> Song 2
> Disarmed GOTO to Song N
> Song 3
> etc.

Possibly only marginally more elegant, but you could use a Start Cue between each song targeting a disarmed Group Cue that plays Song N and stops the sequence of other songs. Each time a song ends this Group Cue will be fired, but until it is armed nothing will happen. I think this requires fewer cues over all, as each time you add a song you only have to add one Start Cue, not a Goto Cue, an Arm Cue and (presumably) a Disarm Cue to prepare the sequence.

I'd stick the sequence in a "Fire first child and go to next cue" Group Cue in a separate cuelist, along with the new Group Cue (as "Fire all children simultaneously"). Then, in your Main Cue List you have a Disarm Cue for the new Group Cue, a Start Cue to start the sequence and an Arm Cue to play Song N as appropriate - and you don't have to deal with the playhead jumping around, or find a way to standby for the cue after Song N (which isn't immediately obvious how to do when using Goto Cues - unless you are in a separate cuelist anyway?).

Rich

[Keith Smith]

This feels like a bug.

I had expected that if a group of auto-follow audio cues was disarmed that it would play out the currently playing cue and proceed to the next armed one. But, as I am sure you know, it doesn't - the pre-wait for all the disarmed cues is executed instead.

Is this deliberate Chris?

K.

On 26 Feb 2012, at 01:44, Golla wrote:

[Chris Bakos]

This sounds like a job for the devamp cue but I am not sure how it would calculate the time remaining on the current playing song. Perhaps someone has written and elegant script for this? 

[George]

Try this......

Place all tracks in a group

Add a fade cue with the target being the group

Select 'stop target' after fade

This has worked for me numerous times. Hope this helps

George Wirges

Wirges Sound Designs

"Just Listen"

On Feb 26, 2012, at 6:37 PM, Chris Bakos <christop...@gmail.com> wrote:

This sounds like a job for the devamp cue but I am not sure how it would calculate the time remaining on the current playing song. Perhaps someone has written and elegant script for this? 

--
Change your preferences or unsubscribe here:
http://groups.google.com/group/qlab
 
Follow Figure 53 on Twitter: http://twitter.com/Figure53

[Chris Bakos]

While this works, it does not accomplish the main goal of allowing the current song to finish before song N is played, it fades the current song in a not so graceful manner. 

[Rich Walsh]

On 27 Feb 2012, at 00:37, Chris Bakos wrote:

> This sounds like a job for the devamp cue but I am not sure how it would calculate the time remaining on the current playing song. Perhaps someone has written and elegant script for this?

You don't need to calculate the time remaining: the Devamp Cue does that automatically. The tricky bit is going to be reassigning the Devamp Cue's target on the fly to the running Audio Cue…

If you have all your Audio Cues auto-following in Group Cue "1" (set to "Fire first child and go to next cue") you could have a Group Cue "2" (same mode) containing a Script Cue, auto-continuing to a Devamp Cue "3", followed by a cue to stop Group Cue "1" auto-continuing to your Song N. The script would be thus:

tell front workspace
set runningCue to first cue of cue "1" whose q type is "Audio" and running is true
set cue target of cue "3" to runningCue
end tell

You don't even need to set any of your Audio Cues to loop… When you GO cue "2" the Script Cue reassigns the Devamp Cue's target, the Devamp Cue starts counting down and when the current song ends Group Cue "1" is stopped and Song N plays.

However, I've tried both Stop Cues and Fade Cues targeting Group Cue "1" - and both of them play about 100ms of the song after the one that is devamped before the stop kicks in…

This doesn't happen using the original Goto Cue method proposed, or the Start Cue version I offered earlier.

Rich

[dan howarth]

thanks rich --- i got this to work pretty well --- i had missed the settings tab in the devamp cue for "fire next cue" and "stop target" etc etc etc .. i was having a confusing time with the auto-continues, but once those settings were checked, it works perfectly. 

i've got group cue "1" set up with four 4 second files and a goto cue at the end so it just keeps looping the group. then i have group cue 2 with the script cue that gives the devamp cue its target. then the stop cue and then the song N .......... also -- i installed .30 of pre-wait on the devamp cue --- so that it has more time to receive the target from the script cue, i guess --- 

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

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

--

dan howarth

520 955 9434

[Rich Walsh]

On 27 Feb 2012, at 02:27, dan howarth wrote:

> also -- i installed .30 of pre-wait on the devamp cue --- so that it has more time to receive the target from the script cue, i guess ---

I didn't find that I needed a pre wait: it's not the most taxing script. If you're worried, make it auto-follow - then the Devamp Cue can't fire until the Script Cue has completed its task.

This pre wait doesn't stop me hearing 100ms of a song I don't want to though...

Rich

[dan howarth]

looks like the .30 pre-wait is unnecessary -- i loaded shorter cues and am still able to get the devamp to happen and song N to fire ... for example, down to .11 remaining on a playing cue and hit space bar once, fires script to target the devamp, fires devamp and then stop and go on song N .... 

[dan howarth]

This pre wait doesn't stop me hearing 100ms of a song I don't want to though...

not sure if this helps --- i'm curious why your 100ms is happening --- 

[Rich Walsh]

On 27 Feb 2012, at 02:53, dan howarth wrote:

This pre wait doesn't stop me hearing 100ms of a song I don't want to though...

not sure if this helps --- i'm curious why your 100ms is happening --- 

Yeah, this workspace is programmed exactly as I described. If you tighten up your edits so that your audio files don't start with a few ms of silence you will hear the next "song" start before Song N kicks in and the group stops. Try replacing your Stop Cue with a Pause Cue to _see_ what I mean too.

I would say the cause of this is that the countdown of the Devamp Cue appears not to be sample-accurate to the remaining time of the Audio Cue it is devamping... Or, an error is creeping in between the Devamp Cue ending and the next cue firing. Sometimes I can get it down to 30ms; even linking cue "1" & cue "2" to fire together doesn't get rid of it...

Rich

[Golla]

Hi Rich and Dan (and everyone else),

Both solutions work for my purposes, and are more elegant than my
original one. Using the devamp strategy works if I put a 0.5s (or
more) pre-wait time on all of the pre-show songs (kills the little bit
of bleed Rich found happens...which was happening in my tests too),
and a half-second of silence between songs in the house is perfectly
acceptable for my purposes this time around. Interleaving start cues
targeting a disarmed group (and then arming that group at a "places"
call) is totally smooth (but requires put a start cue in between every
song...although it doesn't require the pre-waits). I'd then need to
also include a script to disarm the group again in a later cue.

For those looking to do the same thing as I'm trying, I'd go with the
devamp strategy unless you really don't want that little bit of pre-
wait between songs. It's less stuff to mess with, especially if you
want to re-arrange songs in the pre-show list. If you want seamless
(and no silence between songs) you'll have to go with the first
strategy Rich suggested, which is just a little bit more of a pain to
put together (especially if you have a lot of songs in the pre-show
group).

Thanks for your help and expertise! I'm a director who started
designing sound because my producers "couldn't afford" a sound
designer, who now--because of QLab--doesn't mind doing my own sound
design (if it's relatively simple), and I'm also often helping my
directing students take care of their own, simple, sound needs for
their shows. This group and the folks who've contributed to the wiki
(I'm looking at you Rich, among others) have been invaluable in
helping me solve problems.

Andrew

[Rich Walsh]

On 27 Feb 2012, at 05:57, Golla wrote:

> I'd then need to also include a script to disarm the group again in a later cue.

Just for the record, you can use a Disarm Cue for this - no need for scripting! You'll only need to disarm the cue if you're going to play the music again; I'd disarm it _before_ the group is used each time.

Rich

[Chris Bakos]

This script should be added to the Qlab Scripting Wiki. I have had so many times when I wanted to do just this.

[dan howarth]

rich --- i am getting your 100ms bug ... the devamp cue does indeed seem to be stopping the targeted (script-fed) cue, but because of the auto-follows (?) the next track is indeed playing -briefly- before it stops and then i hear the song N file .............. has anyone looked at this a bit more ?? i played with that a bit last night and i don't remember getting anywhere ---- i tried to move the stop cue so that it would happen as the devamp cue ends ..... i also tried to pre-wait song N but i still hear the 100ms bug (if you will). 

i'm thinking that this 100ms bug has something to do with the fact that the audio cues group has auto-follows and that though the devamp cue has stopped the script-fed targeted cue, the group itself happily starts up the next track only to be stopped by the stop cue .. a few milliseconds later ... is this just processing time in the group 2 flow ??? it seems that the devamp cue needs to -also- stop the whole group, not just the script-fed targeted cue. ie, a second devamp cue alongside the first, that devamps the whole group ?? i'm making that up, it's probably not possible to devamp an auto-following group. 

[Rich Walsh]

On 27 Feb 2012, at 22:22, dan howarth wrote:

> rich --- i am getting your 100ms bug ... the devamp cue does indeed seem to be stopping the targeted (script-fed) cue, but because of the auto-follows (?) the next track is indeed playing -briefly- before it stops and then i hear the song N file .............. has anyone looked at this a bit more ?? i played with that a bit last night and i don't remember getting anywhere ---- i tried to move the stop cue so that it would happen as the devamp cue ends ..... i also tried to pre-wait song N but i still hear the 100ms bug (if you will).
>
> i'm thinking that this 100ms bug has something to do with the fact that the audio cues group has auto-follows and that though the devamp cue has stopped the script-fed targeted cue, the group itself happily starts up the next track only to be stopped by the stop cue .. a few milliseconds later ... is this just processing time in the group 2 flow ??? it seems that the devamp cue needs to -also- stop the whole group, not just the script-fed targeted cue. ie, a second devamp cue alongside the first, that devamps the whole group ?? i'm making that up, it's probably not possible to devamp an auto-following group.

I think there is probably a relatively simple workaround, but I've not got time to test it today: rather than have cue "1" be a string of auto-following cues, have it as a "Fire all children simultaneously" Group Cue with appropriate pre waits on each cue. Then, before the Devamp Cue, put in a cue to disarm cue "1": it will then stop following on.

This is actually my preferred method of programming Group Cues, and I often have preshow music overlap – so the next track starts just before the previous one ends (impossible with auto-follows).

I have a little script that will convert backwards and forwards between these Group Cue modes to save you working out the times:

http://wiki.figure53.com/QLab+Scripts+and+Macros#x-General-Convert%20Group%20Cue

Rich

[dan howarth]

On Mon, Feb 27, 2012 at 3:33 PM, Rich Walsh <rich...@mac.com> wrote:

I think there is probably a relatively simple workaround, but I've not got time to test it today: rather than have cue "1" be a string of auto-following cues, have it as a "Fire all children simultaneously" Group Cue with appropriate pre waits on each cue. Then, before the Devamp Cue, put in a cue to disarm cue "1": it will then stop following on.

yes this works -so far- without the 100ms thing ..... basically i replaced the stop cue with the disarm cue --- and readjusted all of the auto-continues & auto-follows in the workspace .... things seem pretty good now. 

[Golla]

In the devamp cue solution, would it work add a line to the script
that sets the devamp cue's target to also set the continue mode of of
the running cue to "does not continue"? It's the auto-follow that's
causes the next song to play for a short bit, right? Of course, you'd
then have to undo that change with a later script (to set up for the
next performance), but that should be do-able (find the audio cue in
group 1 whose continue mode is "does not continue" and change that). I
can't test this until later tonight (have to go teach), but might that
work? Then you wouldn't even need the stop cue (though I'd leave it
just to be safe).

I get your solution Rich, but that's a level of precision that I (as a
sort-of sound designer) don't get to in my "process" (such as it is).

Andrew

> I think there is probably a relatively simple workaround, but I've not got time to test it today: rather than have cue "1" be a string of auto-following cues, have it as a "Fire all children simultaneously" Group Cue with appropriate pre waits on each cue. Then, before the Devamp Cue, put in a cue to disarm cue "1": it will then stop following on.
>
> This is actually my preferred method of programming Group Cues, and I often have preshow music overlap – so the next track starts just before the previous one ends (impossible with auto-follows).
>
> I have a little script that will convert backwards and forwards between these Group Cue modes to save you working out the times:
>

>        http://wiki.figure53.com/QLab+Scripts+and+Macros#x-General-Convert%20...
>
> Rich

[dan howarth]

On Mon, Feb 27, 2012 at 4:10 PM, Golla <andre...@gmail.com> wrote:

In the devamp cue solution, would it work add a line to the script
that sets the devamp cue's target to also set the continue mode of of
the running cue to "does not continue"? It's the auto-follow that's
causes the next song to play for a short bit, right? Of course, you'd
then have to undo that change with a later script (to set up for the
next performance), but that should be do-able (find the audio cue in
group 1 whose continue mode is "does not continue" and change that). I
can't test this until later tonight (have to go teach), but might that
work? Then you wouldn't even need the stop cue (though I'd leave it
just to be safe).

re: changes in the workspace from running a cue -- that script we're running already 

causes a change because it gives the devamp cue a target (previously unassigned) so 

that makes it an unsaved workspace ...... 

this new idea to be scripted would similarly change things into "unsaved" territory. 

though you'd probably want to have a master template of this "house music" idea, 

so saving each show's nightly workspace wouldn't seem that necessary .. 

[Golla]

So I tried adding a disarm cue to the beginning of the group that has
the devamp cue in it and that seemed to stop the auto-follow leaking
problem (the next song still played, so the stop cue is necessary, but
we don't hear it once the group is disarmed, we hear the currently
playing song play out). Someone may want to verify that it is actually
working to solve the 100ms problem, but it sounds like it is to me.

So here's what I have:
1. Group cue of pre-show "House Music", each audio set to auto-follow,
no pre-wait time on any of them.
2. Group cue with the following cues in it
-----Disarm cue targeting Group cue 1, auto-continue to:
-----Script cue assigning the target of the Devamp cue to currently
playing song (see Rich's script above), auto-continue to:
-----Devamp cue (target set by preceding Script cue), set to "Fire
next cue when target's loop ends"
-----Audio cue with the lead-in song, auto-continuing to:
-----Stop cue targeting Group cue 1 (since disarming doesn't stop
audio cues from running, even if they're not audible)
3. Group cue with the following:
-----Fade cue fading out the lead-in song, auto-following to:
-----Arm cue arming Group 1

As Dan pointed out, we get into unsaved workspace territory, so I
chose to include the re-arming step so that it doesn't really matter
if the board op saves or not; for all practical purposes either way
the workspace will open for the next show with the correct settings.

Thank you so much Rich and Dan for figuring this out. It's going in
the book in the sound booth for the next director who wants this to
happen.

Andrew

On Feb 27, 3:42 pm, dan howarth <theater.howa...@gmail.com> wrote:

[Willo]

The best solution I'VE found is to tell the sound operator to use
proper judgement, and simply wait before initiating the starting
sequence "until song 4 is done".

In practise, the audience is likely to notice if you fade a song that
has only just started, or is in the middle of a recognisable verse or
chorus...but generally by about 3/4 through the track you can fade it
anywhere and it won't actually register that the song is finishing
early. If the sound operator is familiar with the songs, s/he can
execute the fade at the most appropriate and discrete moment. (This
may still mean waiting until the final 20 seconds of the track). With
the 'Active Cues' window open this is easy to follow and to trigger
the next cue manually.

Give the 'House Music' Group a decent fade time (about 20 seconds) and
whichever song is currently playing will appear to be fading normally
before you play the cue you intend to start the show with.

Saves a lot of mucking around with code solutions, and is surely more
elegant and efficient?

Cheers,
Craig

~<8>-/=====\--------

On Feb 26, 9:44 am, Golla <andrewgo...@gmail.com> wrote:
>
> Given that our preshow can be unpredictable in length, I'm looking for
> a way of making Song N the next song to play at any point in the
> preshow group. For example, let's say Song 4 is playing, and we're
> ready for places. I'd like to execute something that makes Song N the
> next song to play *when Song 4 is done.* That's the part I'm having
> trouble with. I don't want to fade Song 4 (or whichever) out in the
> middle of it and fade in Song N. I want the music to continue pretty
> much seamlessly, just breaking out of the preshow list and making Song
> N the next to go when the current song is finished.
>

> The best solution I've come up with so far....

> Andrew

[Rich Walsh]

On 28 Feb 2012, at 01:56, Golla wrote:

> So I tried adding a disarm cue to the beginning of the group that has
> the devamp cue in it and that seemed to stop the auto-follow leaking
> problem

Oddly, disarming the group was the first thought I had back when this thread started - but when I tested it it didn't stop the auto-follows from happening. I don't work with Group Cues in that mode so I assumed it was a feature... Now I test it again, it _does_ work - so you can ignore everything I said yesterday about changing the mode of the Group Cue - as you don't need to!

Rich

[Mike Pfeiffer]

I tried to follow this string. My head started to spin and I think I
greyed out.
That said the engineer in me would love to learn the proper technique.
I am sure I will have to refer back at some point.

As is usually the case the slacker in me finds the easiest way to
achieve same result.
I would have given up on programming, put the preshow on a cd and then
gone to have a beer.
I assume you only have Qlab as a source.


Mike

[raymond soly]

Actually Qlab is all that is needed as you can assign different
outputs to any Qs......very easy to bump the Q out at the audio
console faders and start the next one as it's on a different set of
faders.....

Ray

[Richard B. Ingraham]

> -----Original Message-----
> From: ql...@googlegroups.com [mailto:ql...@googlegroups.com] On Behalf
> Of Willo
> Sent: February 27, 2012 10:04 PM
> To: QLab
> Subject: [QLab] Re: Breaking out of a song list gracefully
>
> The best solution I'VE found is to tell the sound operator to use proper
> judgement, and simply wait before initiating the starting sequence "until
> song 4 is done".
>

I have to say I was really wondering if anyone else had the same thoughts I
did. Glad to know I'm not alone. :-)

I know all too well that there are some places where you may not have a
dedicated sound operator, so you really must make everything into a single
GO button push in order for things to run smoothly. (the blessing and the
curse of our computer playback tools that make these things possible)
However I would think that even the most inexperienced operator could handle
simply looking at a cue list with cues linked with autofollows, and when
places is called, simply uncheck the autofollow to the next song, wait for
the current song to end and then start the final song of the preshow.

I didn't test this to try it out, but wouldn't that work? Wouldn't that be
a lot easier than all the attempts at complex scripting and such, just to
save a few timely mouse clicks by a board operator?

Maybe it's just me? :-)

Richard B. Ingraham
RBI Computers and Audio
www.rbicompaudio.20m.com

[ra byn (robin)]

On Tue, February 28, 2012 11:52 am, Richard B. Ingraham wrote:
> I didn't test this to try it out, but wouldn't that work? Wouldn't that
> be
> a lot easier than all the attempts at complex scripting and such, just to
> save a few timely mouse clicks by a board operator?

It works. I was in a rehearsal the other day & the SM wanted to link a
group of cues with autos. At some point he said, "we need to stop after
the next one" & so I unchecked the cue that was running & told him, I'm
not sure it's going to stop. It did, no problem.

Of course the simplest solution is to do all this manually but we're
working with computers & software & to so degree I see all this "how do we
do something almost everyone has to do over & over" automatically.

In my view what we are needing is a spcific cue that covers a situation
many of us need often. A walk in group / cue / etc...

Can it be done with scripts & extra programming & such? Sure but the same
thing could be said about other conveniences in Qlab. Once a task requires
more than a few steps, I think it asks the question. What is missing from
the tool bar.

These discussions are paving the way for Figure 53 to understand what that
tool might look like. Until then, we're left to invent it with other tools
which isn't the same thing as the right tool.

*

[Richard B. Ingraham]

I do agree with you for the most part. Having a discussion about what new
tasks need to be performed on a regular basis is always a good thing.

At the same time, maybe this is me just getting older and more nostalgic???
But I do feel that often simple tasks seem to be made more and more
complicated simply because of the fact that there is some fear an operator
might make some mistakes once in a while. When in the "old days" you would
just have the operator listen and move a couple of faders and push a few
buttons, there is this growing reluctance to have the operator do anything
more than push a GO button on command. Which to me personally is very
sad.

Don't get me wrong, I love our modern tools and I have no desire to go back
to running shows with multiple "decks" (digital or analog) and doing every
fader move by hand. I just think there is a balance that can be struck. As
there is a case to be made that the more simple it becomes the less and less
need there is for skilled staff and that is OK until the proverbial hits the
fan and then you need someone with some skill and judgment to fix the
problem in the most graceful and expedient way possible. A good board op
can do that. But if we drive them all away by making their tasks
meaningless, then they won't be around when we need them.

Of course I understand that there are always going to be venues and
situations where you do need to make it all as canned and foolproof as is
humanly possible. I've done plenty of themed entertainment and work in
companies where the Stage Manager runs sound and lights to know this all too
well.

I guess this thread just got me thinking about this subject a bit more than
usual is all. It's more about the general concepts than a comment about
this particular case or example.

Just something to chew on. Sorry for taking the thread off on a tangent.

Richard B. Ingraham
RBI Computers and Audio
www.rbicompaudio.20m.com

> -----Original Message-----

> From: ql...@googlegroups.com [mailto:ql...@googlegroups.com] On Behalf

[fnmc...@yahoo.com]

I always make a series of auto continued fade outs for pre show. So no matter which song is playing they all go out.

Sent from my iPhone

[Richard B. Ingraham]

> -----Original Message-----
> From: ql...@googlegroups.com [mailto:ql...@googlegroups.com] On Behalf
> Of fnmc...@yahoo.com
> Sent: March 02, 2012 12:12 PM
> To: ql...@googlegroups.com
> Cc: <ql...@googlegroups.com>
> Subject: Re: [QLab] Re: Breaking out of a song list gracefully
>
> I always make a series of auto continued fade outs for pre show. So no
> matter which song is playing they all go out.
>

I often do that as well. However that would not have achieved what the
original poster of this thread was trying to do.

[Richard B. Ingraham]

Well that’s kind of my point..  J

 

Are our board ops so incompetent that they cannot handle such simple tasks as the two you outline?  I  know in some situations the answer is going to be yes.  And in others I would argue that we (sound designers, or whomever is in “charge”) sometimes can go a bit overboard in simplifying things.

 

Locking and unlocking a workspace is one mouse click if I’m not mistaken. The preshow could all be put in its own cue list so if anything was altered by accident, it would only be the preshow.  Then relock the workspace when that is done. 

 

I work in plenty of places where Lights and Sound are run by the same person.  But I also work in many where they are not the same person and a few places where work rules wouldn’t even allow that to happen. 

 

I guess my point was rather than jumping through a series of complex hoops, which may or may not work as expected (at least that is the feeling I got from reading the thread) wouldn’t it be easier to just make the op actually do something?  LOL   If you don’t have the crew/staff to do it, that’s another matter of course.

 

Anyway, I got off into a more philosophical tangent there…  sorry for pulling it off topic..

 

 

Richard B. Ingraham

RBI Computers and Audio

www.rbicompaudio.20m.com

 

 

 

 

From: ql...@googlegroups.com [mailto:ql...@googlegroups.com] On Behalf Of Chris Bakos
Sent: March 01, 2012 11:54 PM
To: ql...@googlegroups.com
Subject: Re: [QLab] Re: Breaking out of a song list gracefully

 

While this is true it leads to a whole series of other problems that would have to be corrected:

 

1) your workspace cannot be locked  and other unintentional changes could be made that could jeopardize the fucntioning of the show.

2) Your operator would have to know the change that auto follow back and/or close the project without saving each and every show.

 

Often your operator is doing both sound and lights (also a blessing and curse of our modern tools) and the extra work associated with training them to look for and pick the right song when they may have several other things happening ( house lights, spot operation, etc...) is often just not really practical. 

If I can make Qlab do it and keep my operators from having to, I will make Qlab do it every time. 

  

[Willo]

There's no need to write complicated code, OR to unlock your workspace!

Put your house music tracks (all except the Final one) in a group called "House Music". Have them all auto follow.

After the last track, auto follow with a "Play Track 1" cue, which sends it back to the first song in the group.

So far so good, you have a set list as long as you like, set to 'play all and then repeat'.

Meanwhile, your next loaded cue is lined up ready to play. It's a Group cue called "The Show Starts"

Two cues within, set to trigger simultaneously:

1) Fade the Group called "House Music". (Doesn't matter where you are in the playlist, any currently playing track will fade, and if you like, stop. I recommend a 20 sec fade and then tweak to suit yourself.

2) Play your "Final Track" - the one you want to precede every show. (If necessary, give it 5 secs or so of Pre-wait, to start nicely after the other House music has faded.

Now, to avoid the problem you had of not wanting a track to fade too early, you're going to have to trust your operator to GO on the VISUAL CUE of "watch the currently playing track and Go when it's down to it's final 10 seconds". (They can watch the cue countdown in the main window, or have the "Active Cues" window open, or both.)

I'm assuming you normally trust your operator to GO on either a verbal cue from an actor, a visual cue from some other stage business or a lighting change...?

- What's the difference??

When GO is hit at the correct visual:

1) the currently playing track (which is close to finishing anyway), will fade. The song will vary every night according to circumstance, but it will always play to it's proper end.

2) your "Final track" will play at the top of the show; same song every night. The transition will be seamless.

3) you've just played "The Show Starts" and your next cue is already loaded. 

Sorry if I'm spelling this out simplistically, but I see it as a simple solution to a simple problem.

If your operator can't handle going on this visual reference, how do you trust them to GO at any other cue reference...?

Cheers,

Craig

~<8>-/=====\--------

[dan howarth]

On Sat, Mar 3, 2012 at 12:09 AM, Willo <crgw...@bigpond.com> wrote:

There's no need to write complicated code, OR to unlock your workspace!

i've had some interesting experiences in the last few months with our sound guy -- 45 years in the business, new to mac os in the last year or so, new to qlab etc. i've had fun watching him learn qlab, come up with ways to do things that i wouldn't have tried. the program is quite versatile. there's always a lot of different ways to accomplish the same task and create the desired effect. furthermore, i've had a great time reading emails from this listserv about various ways to make things happen ....... however, all this discussion of ... whether to trust humans ... i'm a bit surprised that we got here. 

here's my opinion -- the beauty of QLAB (and its parent, mac os x) is the cross-talking and self-referential recursion of the workspace and its protocols .. ie, i like to do things this way. he likes to do things that way. no matter which way to do it, it will work ... sometimes we should use human judgement, sometimes we should use automation. you'll know when. (maybe after the first tech-rehearsal you'll change your mind). etc. 

here's my point -- there is no right or wrong way; yes there are better ways. (a famous man once said something similar about whiskey) .. 

[Jeremy Lee]

You know you can put them all in a group cue and fade the group in a single fade, right?

On Mar 2, 2012, at 12:12 PM, fnmc...@yahoo.com wrote:

I always make a series of auto continued fade outs for pre show. So no matter which song is playing they all go out. 

-- 

Jeremy Lee

    Sound Designer, NYC - USA 829

        http://www.jjlee.com

[Andy Dolph]

On Fri, Mar 2, 2012 at 10:58 AM, ra byn (robin) <ra...@rabyn.com> wrote:

Can it be done with scripts & extra programming & such? Sure but the same
thing could be said about other conveniences in Qlab. Once a task requires
more than a few steps, I think it asks the question. What is missing from
the tool bar.

I wonder if it would be useful to be able to use scripting and essentially create our own  new cue types that could be added to the toolbox on our own copies of Qlab....  

probably opening a big can of worms - but just a thought...

Andy

[Rich Walsh]

I would have replied earlier to the last few responses on this thread, but I've been away...

The solution we collectively arrived at does not involve any "complicated code": it's a two line script. The original post had a perfectly workable solution to the problem; it took us a few emails back and forth to come up with something slightly more elegant: this is, after all, a _discussion_ list. I'm sorry for those of you who felt that the fact that we couldn't solve this in less than 5 posts means that we should have given up on the whole thing... I guess you don't use Devamp Cues at all, as surely your operators are all good enough to go on the beat as well?

I had to do exactly this process on the first show I designed and operated 21 years ago: with 2 Revoxes and a stopwatch. I think it's a bit luddite to dismiss the idea of automating such a process so out of hand: I'd be disappointed if two decades on it still wasn't possible to have one cue follow another automatically without the operator watching a countdown timer. I'd rather my operators put their energy into things that can't be automated, like listening, mixing, and hand-shaping fade curves to match the speed of the actions onstage... If, when I'm working as an operator, a designer asked me to watch a clock for a cue point I would certainly look for a way to avoid such a menial task!

You don't have to program in the ways other people discuss here, but I think it's a bit rude to tell them that they shouldn't be exploring ways of using QLab's inherent functionality to solve the problems they encounter.

Rich

[cedricl]

This is exactly what I've done too. He could then have an auto follow after the group fade that plays the song he wants.

On Sunday, February 26, 2012 4:54:33 PM UTC-8, Wirges Sound Designs wrote:

Try this......

Place all tracks in a group

Add a fade cue with the target being the group

Select 'stop target' after fade

This has worked for me numerous times. Hope this helps

George Wirges

Wirges Sound Designs

"Just Listen"