[QLab] Multiple Workspaces

[Paul Arditti]

List - 

I'd like to be able to run two workspaces at the same time on one machine. One with sound effects, the other with music backing tracks. 

The GO on the cue list of sound effects is to be triggered by the sound operator. The GO on the cue list of backing tracks is to be triggered by the musical director. The two workspaces don't need to sync at any point (although they will both be playing simultaneously), and in fact I'm only suggesting two separate workspaces because I need to see both cue lists up on the screen at the same time.

I'm going to map the GO in each workspace to a separate midi and key command, so that the GO from each operator can't trigger the other's cue list.

My only issue is that the GO only seems to work on the active workspace. Is there an elegant workaround? Or is there another way to see two cue lists simultaneously but trigger each one independently?

Thanks, 

Paul

Paul Arditti Sound Design Ltd.

paula...@btinternet.com

www.paularditti.com

UK mobile: +44 7976 355 043

[Fergus Mount]

Hey Paul,

You can select the cue list you want to trigger on the right hand cue list tab, and in the inspector window you can assign individual cue lists a MIDI or Key trigger. The only drawback we found doing it this way was that the cue list didn't scroll down when the highlighted cue reached the bottom of the page, so the operator has to manually scroll the window down to follow the cues.  We found this was ok for tech but we changed it back to the active cue list method in the preferences for the shows.

Hope this helps!

Fergus

2009/10/18 Paul Arditti <paula...@btinternet.com>

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

[Sten]

Hello Qlab Wisdom,

This summer I was using MSC standby + and standby - commands to allow
my operator to chose his playback position via a remote midi button
box (I did MIDI note on to MSC translation via a MaxMSP patch). This
worked great, with the cursors unlocked I was able to be editing one
cue while he navigated to whatever cue was about to be rehearsed
without needing the keyboard. The added bonus was that standby also
loaded the cue, so he didn't need to hunt down the keyboard and hit
"L" to be ready to fire.

I'm trying this same thing now with the newest version of Qlab and the
Qlab response to MSC Standby commands has changed and now mimics the
normal select previous and next commands. The MSC Sequence commands
have picked up the slack here but my current situation as presented a
new problem; the playback position submerges into the subcues of a
group even when the groups are collapsed.

I'm not wedded to the idea of using MSC, it was just a means to an
end. What I need to do is allow the playback position in the cuelist
to be adjusted remotely via MIDI, even while the playback position and
selected cue are not following one another, and respect the collapsed
or uncollapsed state of the cuelist. I also need for the currently
selected cue (or group as the case may be) to be automatically loaded
for immediate playback.

I realize that this "autoloading" method makes for very slow
navigation through the cuelist but it's absolutely necessary for my
musical director who is triggering recorded tracks. If he ever has a
reason to jump around in the cuelist (which he does via a remote
button box) during a performance it needs to load as soon as possible.

I'm willing to bet that there is a script that can do this but my
scripting prowess is, well, non-existent. Thoughts? Solutions?

Thank you,

Sten

[Christopher Ashworth]

Hi Sten,

Thanks for describing this scenario. The MSC Sequence +/- commands do
intentionally go into the collapsed groups (if the next sequence is
inside the group) because this is a necessary consequence of their
semantics.

Thinking over this MSC STANDBY+/- issue suggests the following
possibility, about which I'd like to get the feedback of the list:

I'm thinking what I should probably do is tweak the standby+/-
behavior just a bit more so that it is more appropriate when the
playback position and selection are not locked (as in Sten's case).
The new behavior would move the playback position in the same way that
the selection is moved. As such, they would be identical behaviors
when the playback position is the same as the selection, but it would
allow the playback position to move independently of the selection
when they are not the same.

Another tweak would be to then load the cue at the new playback
position, to restore that part of the standby+/- behavior.

I think this is probably the behavior modification I should have made
when changing it in the last release, but didn't think about the
scenario Sten described, so I did the simpler modification of just
making it move the selection.

Thoughts? Concerns? I'm guessing there is probably someone out there
who just wants the current behavior, so we may need to hash out which
is the best compromise.

Thanks,
Chris

[Jason Crystal]

Chris,

I'd also vote for the ability for MSC to standby the Playback position
rather than the Selection, and then standby appropriately.

Thanks for looking into this!

-Jason

[sam kusnetz]

> I'd also vote for the ability for MSC to standby the Playback position
> rather than the Selection, and then standby appropriately.

+1 for this idea...

i think it's safe to assume that MSC commands are coming from an
operator, and since the only reason to uncouple the playback position
and the selection position would be to have editing and operating
going on simultaneously, then the MSC commands should favor the
operator who doesn't have the mac keyboard under his fingers, rather
than the designer who does.

right?

i think so.

-sam

[Sten]

Hello Everyone,

As I dig into QLab for track playback I have some questions. I
realize that many of these issues have been talked about at various
times and I apologize if I'm duplicating previous discussions that I
missed. I will put each item in a different email messages so that
the threads make sense.

So. Click track. My music department is giving me files that start
directly on the first beat. The click is basically a single square
wave. With guaranteed synchronization turned on I have to add between
700 and 1000 samples of silence at the front of the cue in order to
get the first click --depending on the system. With that option
turned off I get a click but not the entire first click every time.
Basically the first click feels soft and lacking in high end which I
think means that the very beginning is getting cut off. When I get a
chance I will record the output to see what is exactly happening.

Since I know nothing about how to program this stuff, I'll just put it
out there that I'm very interested in finding a way to get
synchronized audio that can automatically deal with the processing
latency of the system. When synchronization is not engaged it seems
strange that the first click isn't getting out loud and proud.

In the short term, does anyone have any audio utilities that can
easily join two audio files together? The idea of having to open each
one of these files in an editor and slip in 20ms of silence is giving
me hives. A program that can batch process would be particularly
fantastic.

Thanks,

[Christopher Ashworth]

On Oct 20, 2009, at 3:53 PM, Sten wrote:
>
> So. Click track. My music department is giving me files that start
> directly on the first beat. The click is basically a single square
> wave. With guaranteed synchronization turned on I have to add
> between 700 and 1000 samples of silence at the front of the cue in
> order to get the first click --depending on the system.

Guaranteed sync will need to drop an unpredictable number of frames
from the top to accommodate overhead and therefore synchronize to any
other cue(s) in the workspace that may have been told to start at that
same time.

> With that option turned off I get a click but not the entire first
> click every time.

Should be the entire first click every time. With sync turned off all
frames are guaranteed to play, except under possible error
conditions. (Does the console log show any errors?)

> Since I know nothing about how to program this stuff, I'll just put
> it out there that I'm very interested in finding a way to get
> synchronized audio that can automatically deal with the processing
> latency of the system.

The trick is that the processing latency cannot be predicted. It will
be different every time, due to the way a non-realtime operating
system like OS X (or Windows) functions.

I've been thinking through some possible architectures that could
accommodate this problem in future versions of QLab, but it's not a
trivial issue.

> When synchronization is not engaged it seems strange that the first
> click isn't getting out loud and proud.

As far as the QLab part of the audio chain, all frames should be
delivered as represented in the file.

Best,
Chris

[Jeremy Lee]

Hey Sten,

Just a stupid couple of questions- is the cue preloaded when it's
doing this? Are all parts of the group set to Guarantee
Synchronization?

Have you tried putting a pre-wait on all the parts of the group of
20ms (or whatever you need)? Or adding a 20ms long silent audio file
at the top of the group (as a separate file, not merged into the MDs
tracks). I'll bet one or both of these will work. My guess is that
the buffer of the audio driver is large enough that by the time QLab
says "play this" the window is closed for that audio 'frame', and it
starts playing in the next buffer window.

So, if you have a .02s prewait on everything, QLab can say "in 20ms, I
want you to play this". It should work, and the delay should be
predictable by the MD.

That way, I can avoid bringing you cream for your hives. Ewwww...

Jeremy

On Oct 20, 2009, at 3:53 PM, Sten wrote:

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

[Christopher Ashworth]

On Oct 21, 2009, at 11:39 AM, Jeremy Lee wrote:
> is the cue preloaded when it's doing this?

Preloaded won't matter when guaranteed sync is off; it'll take longer
to play the file but it will start from the beginning and not drop
frames.

> Have you tried putting a pre-wait on all the parts of the group of
> 20ms (or whatever you need)?

Adding a pre-wait won't help here.

> My guess is that the buffer of the audio driver is large enough
> that by the time QLab says "play this" the window is closed for that
> audio 'frame', and it starts playing in the next buffer window.

While the buffer requested by the driver is an important
consideration, in this case it will just mean adding delay to when the
first frame goes out. When guaranteed sync is off the cue will wait
until the next request from the driver to deliver the first frame, and
then continue supplying all frames from there.

-C

[Sten]

Speaking again as a neophyte at best, is there any method by which
QLab cues up audio to guarantee sync but waits to send audio until the
driver has made its next request?

-Sten

[Christopher Ashworth]

Hi Sten,

On Oct 22, 2009, at 10:50 PM, Sten wrote:

> Speaking again as a neophyte at best, is there any method by which
> QLab cues up audio to guarantee sync but waits to send audio until
> the driver has made its next request?

One way you could do this is to put all the tracks into a single file,
and then turn of "guaranteed sync" for that one cue. All the tracks
within the cue will still be synchronized, and the cue will wait to
start playing until the first request from the driver.

Cheers,
Chris