[QLab] Bundling Workspace - Cue drop outs

140 views
Skip to first unread message

Panos Couros

unread,
Jul 12, 2009, 8:04:17 PM7/12/09
to ql...@lists.figure53.com
Hi everyone

I'm running my first show on QLab, and am hugely impressed with what I
can achieve with it. Am running both sound and video to 3 x stereo
pairs of speakers and a data projector.

We are about to open, so have been running preview shows. Yesterday,
after all of the changes have now been made, I decided to bundle the
workspace and work from the new bundled file.To my horror, several
cues did not fire up during a run (with audience), and an early fade
which had been programmed in did not calculate. On later inspection I
saw that the fade drawing had shifted (this was a fade drawn in to the
settings tab area)

Now I am feeling very uncomfortable. Will everything go to plan on
opening night? Has anyone had this similar problem, and is there a way
to ensure total integrity, without running through the show cue by
cue, before the run?

cheers and thanks

Panos
________________________________________________________
WHEN REPLYING, PLEASE QUOTE ONLY WHAT YOU NEED. Thanks!
Change your preferences or unsubscribe here:
http://lists.figure53.com/listinfo.cgi/qlab-figure53.com

*

unread,
Jul 12, 2009, 10:16:11 PM7/12/09
to Discussion and support for QLab users.
Hope is not a reliable form of testing.

I've had dual crashes in the middle of a show where I didn't have a chance
(make the time) to check all my cues after making changes. The only way to
know that the show works is bundle, restart, load it & test it real time
IMO.

One of the things that has burned me a few times is setting up OSX to boot
to a show file. Then I forget to change the show file listing after
updates during a rehearsal. Then the next day I'm unknowing work from the
old show file & wondering where all my changes are until I realize what
has happened.

Every time I make a change I review the complete cue sequence at a minimum.

If possible, I trigger everything from the beginning of cue list to the
end & listen diligently. Sometimes as doors are opening with headphones on
& the channels muted at the console. Sometimes I'm review ACT II during
the intermission. It's become by goal in life to never run cues for an
audience I haven't personally witnessed work.

Shy of a complete check, you're taking a risk. The worst part is, once
you've had a cue not work & one go wrong in a show, no one trusts your rig
any more. It's hard to work back from that:(

*

On Sun, July 12, 2009 7:04 pm, Panos Couros wrote:

> Will everything go to plan on opening night? Has anyone had this similar
> problem, and is there a way to ensure total integrity, without running
> through the show cue by cue, before the run?

________________________________________________________

Richard B. Ingraham

unread,
Jul 12, 2009, 11:02:48 PM7/12/09
to Discussion and support for QLab users.

> -----Original Message-----
> From: qlab-b...@lists.figure53.com [mailto:qlab-
> bou...@lists.figure53.com] On Behalf Of *
> Sent: Sunday, July 12, 2009 10:16 PM
> To: Discussion and support for QLab users.
> Subject: Re: [QLab] Bundling Workspace - Cue drop outs
>
> One of the things that has burned me a few times is setting up OSX to
> boot
> to a show file. Then I forget to change the show file listing after
> updates during a rehearsal. Then the next day I'm unknowing work from
> the
> old show file & wondering where all my changes are until I realize what
> has happened.

If I could make a suggestion here.....

The way to prevent this from happening is to only have 1 version of your
show file on the machine actually doing the playback. So for example I will
just save over the old file as I do the editing/changes as tech rehearsals
progress.

Now I do back it up of course, but I back up that file periodically to my
laptop or some other external drive (external hard drive, thumb drive, what
have you) as tech progresses. Typically I back up at the end of every tech
session. So end of the day, dinner breaks, etc... I create a new folder in
the back up location with a date and number, so I have multiple days and
versions worth of back up/archive when I am done.

This achieves the same amount of back up and redundancy, but it only keeps
one version (the most current) of the show itself on the computer doing the
playback. No chance for an operator to accidentally load an old version or
the like.


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

Panos Couros

unread,
Jul 13, 2009, 7:46:41 AM7/13/09
to ql...@lists.figure53.com
Thanks for your comments guys.

So, am I to believe that I should only test run through the cues after
I have made a CHANGE to the file? Otherwise, I should trust that
everything will work fine? Or is this necessary after every time the
file is opened? If all of the cues work, then they should always work
- correct?

I need my trust restored in this software as we move into an opening
night full of critics!

cheers

Panos

Christopher Ashworth

unread,
Jul 13, 2009, 8:01:35 AM7/13/09
to Discussion and support for QLab users.
On Jul 12, 2009, at 8:04 PM, Panos Couro

>
> We are about to open, so have been running preview shows. Yesterday,
> after all of the changes have now been made, I decided to bundle the
> workspace and work from the new bundled file.To my horror, several
> cues did not fire up during a run (with audience),

Were you able to determine the reason they did not run?

> and an early fade
> which had been programmed in did not calculate. On later inspection I
> saw that the fade drawing had shifted (this was a fade drawn in to the
> settings tab area)

I would love to see a before and after version of this workspace, if
possible. I am startled that the bundling process would have changed
a fade curve--and obviously would really need to fix that.

The bundle should not change anything about the workspace--in fact
during the majority of the process it is using the exact same code
that simply saves the workspace. So if it ever does otherwise I need
to know and fix it, and any details that can be provided would be
tremendously appreciated. Send 'em to sup...@figure53.com.


On Jul 13, 2009, at 7:46 AM, Panos Couros wrote:
>
> So, am I to believe that I should only test run through the cues after
> I have made a CHANGE to the file?

Well, not the entire file, but it is usually a good idea to test a
change you make to make sure it sounds or looks the way you thought it
would sound or look.

But that's a separate issue from the problems you originally
described, where it sounds like the workspace became corrupted.

> Or is this necessary after every time the file is opened?

No.

> If all of the cues work, then they should always work - correct?

Correct.

Best,
Chris

John Taylor

unread,
Jul 12, 2009, 10:34:07 PM7/12/09
to Discussion and support for QLab users.
I couldn't agree more. I have been using QLab for years now and this year achieved my 1000 show, Glitch free. I am not saying that things have worked first time but rather that through a very strict Design and Pre Show testing procedure I have eliminated these types of mistakes. Sure there may be a bug there but that isn't the reason for the show stop.  In designing QLab shows I use three basic rules. DOCUMENT(Label). TEST. BACKUP.

cheers

John

On 13/07/2009, at 12:16 PM, * wrote:

Hope is not a reliable form of testing.

I've had dual crashes in the middle of a show where I didn't have a chance
(make the time) to check all my cues after making changes. The only way to
know that the show works is bundle, restart, load it & test it real time
IMO.


John Taylor
SOUND DESIGNER
Gold Coast Voice Studio
Ph: (07) 55649553
Mobile: 0419676213




Jeremy Lee

unread,
Jul 13, 2009, 8:18:35 AM7/13/09
to Discussion and support for QLab users.
Are you sure that they just didn't play? Were there red "X"s over the
little icon on the left? Remember that when you move a show to a new
computer, you have to double-check that the device assignment and
matrix is set up correctly.

And DEFINITELY, always listen to changes before you open the house.
It's easy to make a stupid mistake that can kill the show- replacing
the file on the wrong Q, etc. And especially with something as
extreme as bundling and moving to another computer- you need to make
sure that it all worked correctly. It always does, but if you need
confidence, it's the only way.

I'm guessing though, that since you didn't mention any red "X"s, the
bundling worked just fine, but when moved to another computer, the
device assignment/ matrix wasn't set up correctly. Look at that
before anything else.

Jeremy

On Jul 13, 2009, at 7:46 AM, Panos Couros wrote:

> Thanks for your comments guys.
>
> So, am I to believe that I should only test run through the cues after
> I have made a CHANGE to the file? Otherwise, I should trust that
> everything will work fine? Or is this necessary after every time the
> file is opened? If all of the cues work, then they should always work
> - correct?
>
> I need my trust restored in this software as we move into an opening
> night full of critics!

--
Jeremy Lee
Sound Designer, NYC - USA 829
http://www.jjlee.com

Panos Couros

unread,
Jul 13, 2009, 10:04:45 AM7/13/09
to ql...@lists.figure53.com
I will try and respond to each question below:

> Are you sure that they just didn't play?  Were there red "X"s over the  
> little icon on the left?  

The operator assured me that no sound was being produced, but he was
watching the files playing - so yes they were playing, but not
outputting any audio. Everything was assigned as normal, so no red X's

> And DEFINITELY, always listen to changes before you open the house.
 

I did listen to the changes, as well as picked random parts of the cue
list to listen to. All seemed well. The cues that did not work
however, were both not changed, and not previewed after the bundle
process. The changes were fine (apart from the fade curve)

>Were you able to determine the reason they did not run?

No, it is still a mystery. I was always using the same cue list
through tech, previews etc. During this process many things were
changed, and some sx and vx sources ended up in various directories.
Prior to bundling, I made a change to one last file (the one that had
a fade in it) and checked the file in settings to see if it looked OK,
which it did. I had changed files with fade curves before successfully
and knew this was reliable.

So, I had my final cue list and decided to bundle everything so that
all the files would be compiled in the one place, and that I could
back up a final version of the show on external hard disk, as a
safety. This new version was opened and random tested. It was this new
version that dropped the playback of several cues as well as lost the
fade.

Tomorrow i will go in prior to the performance and run through all of
the cues to make sure they all play back. If they do, I trust that
they will play back again for the performance and for all subsequent
performances, where I will not be in attendance.

How can I ascertain if the file is corrupted in any way?

Any further advice? Thanks for the assistance and feedback so far - I
appreciate it!

cheers

Panos

Christopher Ashworth

unread,
Jul 13, 2009, 4:36:24 PM7/13/09
to Discussion and support for QLab users.

On Jul 13, 2009, at 10:04 AM, Panos Couros wrote:

> I will try and respond to each question below:
>
>> Are you sure that they just didn't play? Were there red "X"s over
>> the
>> little icon on the left?
>
> The operator assured me that no sound was being produced, but he was
> watching the files playing - so yes they were playing, but not
> outputting any audio. Everything was assigned as normal, so no red X's

That does sound like a patching/routing issue for the audio device,
which means it might be "normal" behavior. (You will often need to re-
patch all external audio & video hardware when you move to a new
computer, so that QLab "knows" how to connect your workspace to the
new equipment.)

> How can I ascertain if the file is corrupted in any way?

In this case "corruption" would probably only mean that the settings
were not transferred properly, and so the file is not identical to
what it should be. So the only way to determine that would be to
notice it and see that the settings are not what you expect.

Best,
Chris

mick ritchie

unread,
Jul 14, 2009, 4:02:25 AM7/14/09
to Discussion and support for QLab users.

On 13 Jul 2009, at 21:36, Christopher Ashworth wrote:

>
>
> That does sound like a patching/routing issue for the audio device,
> which means it might be "normal" behavior. (You will often need to

> re-patch all external audio & video hardware when you move to a new

> computer, so that QLab "knows" how to connect your workspace to the
> new equipment.)
>
>> How can I ascertain if the file is corrupted in any way?
>
> In this case "corruption" would probably only mean that the
> settings were not transferred properly, and so the file is not
> identical to what it should be. So the only way to determine that
> would be to notice it and see that the settings are not what you
> expect.

Im reading and learning here but is it possible that the bundling
command transfers the already saved version of the workspace and none
of the changes made since the last save? I seem to remember some
renaming not bundling across for me on tests once but im a
compulsive apple S'er usually.

mick

Panos Couros

unread,
Jul 14, 2009, 12:38:20 PM7/14/09
to ql...@lists.figure53.com
HI all

Well, Opening night went without a hitch, and was a critical success
too!

I did however go in before and play every cue, just to make sure.

Thanks for all of your suggestions - I listened, learned and applied!

Is Qlab from now on!

cheers

Panos

Christopher Ashworth

unread,
Jul 31, 2009, 2:44:04 PM7/31/09
to Discussion and support for QLab users.
Belatedly,

On Jul 14, 2009, at 4:02 AM, mick ritchie wrote:

> Im reading and learning here but is it possible that the bundling
> command transfers the already saved version of the workspace and
> none of the changes made since the last save? I seem to remember
> some renaming not bundling across for me on tests once but im a
> compulsive apple S'er usually.

Good idea, and one that I just attempted to test. It doesn't look
like this scenario (bundling before a save) is causing corruption,
though. At least in my tests.

I'm going to continue working on it, but if anyone knows of a
consistent way to lose information please drop me a line off list.
(Specifically, I'm trying to determine if the Audio Cue integrated
fade envelope, and possibly the start and end times can be lost during
a bundle. And if so how to make it happen!)

Best,
Chris

Reply all
Reply to author
Forward
0 new messages