[QLab] Powerpoint and qLab

[Gmail 2]

The theatre production I am currently working on requires the use of
both projections and audio cues. The director of the show designed the
projections as a powerpoint presentation. The audio cues are all
loaded into qLab. We are running the projector off an iMac. The
problem I'm having is when I'm running powerpoint full screen on the
projector I can't operate qLab, because when I go to hit go, it brings
qLab to the front (on just the monitor, not the projection screen)
which causes the powerpoint show to hide in the background leaving
just my desktop image on the projection screen. Aside from dumping all
the slides onto qLab, is there a way to make these two programs play
nice?
________________________________________________________
WHEN REPLYING, PLEASE QUOTE ONLY WHAT YOU NEED. Thanks!
Change your preferences or unsubscribe here:
http://lists.figure53.com/listinfo.cgi/qlab-figure53.com

[Andy Dolph]

why not just export the slides as jpegs and load them in QLAB - I
think that'd be the easiest way to do it.

Andy

[Jason Eckenroth]

Warning: snarky response!

You could take the vga out from the (obviously windows pc) laptop
running the powerpoint presentation, put it through a firewire video
interface, then run it as a camera cue in QLab. Then get one o'them
bluetooth midi connections to run back to the pc laptop and have it
mimic a mouse click so you can advance slides, also from QLab. I
don't actually know what hardware or software it would take to
accomplish that.

...or you could just bounce the slides as jpegs. It would seriously
be faster. Unless you're worried about some slick animations you
might have in the slides, in which case I'd still think that
rebuilding them or taking a video of them with iShowU HD(and then
using video cues in QLab, making sure to play/pause/stop to make the
animations work like they did in PPT) would be easier.

Sorry about the first snarky response, I just thought the rube
goldberg approach was too silly to not share. Hope I helped a little
bit.

-JME

[Drew Dalzell]

On Oct 14, 2010, at 12:39 PM, Jason Eckenroth wrote:

> Warning: snarky response!
>
> You could take the vga out from the (obviously windows pc) laptop

"We are running the projector off an iMac."

So yeah, kinda obviously a Mac PC.

[Jason Eckenroth]

Again, I don't mean to be too snarky, but I did add that for rube
goldbergian effect. Also the word goldbergian.

[Rich Walsh]

On Oct 14, 6:11 pm, Gmail 2 <andrew.m.wilh...@gmail.com> wrote:
> The theatre production I am currently working on requires the use of  
> both projections and audio cues. The director of the show designed the  
> projections as a powerpoint presentation. The audio cues are all  
> loaded into qLab. We are running the projector off an iMac. The  
> problem I'm having is when I'm running powerpoint full screen on the  
> projector I can't operate qLab, because when I go to hit go, it brings  
> qLab to the front (on just the monitor, not the projection screen)  
> which causes the powerpoint show to hide in the background leaving  
> just my desktop image on the projection screen. Aside from dumping all  
> the slides onto qLab, is there a way to make these two programs play  
> nice?

If you trigger QLab via MIDI it doesn't come to the front. I've just
mocked up what you describe with my second monitor and - nastiness of
PowerPoint aside - it seems to do what you need...

If you have no transitions then wouldn't a screenshot of each slide
make a still image you could use in QLab without much effort? How are
you triggering PowerPoint?

Rich

[be...@danceplace.org]

If you do need the transitions, you can try exporting the Powerpoint as a movie, though if the specific transitions are not supported by quicktime, they will not look the same in the movie file. If that is the case, you can take a video screen shot, using a program like screencast-o-matic.com to accurately capture all transitions.

~Ben

On Oct 14, 6:11 pm, Gmail 2 <andrew.m.wilh...@gmail.com> wrote:
> The theatre production I am currently working on requires the use of  
> both projections and audio cues. The director of the show designed the  
> projections as a powerpoint presentation. The audio cues are all  
> loaded into qLab. We are running the projector off an iMac. The  
> problem I'm having is when I'm running powerpoint full screen on the  
> projector I can't operate qLab, because when I go to hit go, it brings  
> qLab to the front (on just the monitor, not the projection screen)  
> which causes the powerpoint show to hide in the background leaving  
> just my desktop image on the projection screen. Aside from dumping all  
> the slides onto qLab, is there a way to make these two programs play  
> nice?

[Paul Gotch]

On Thu, Oct 14, 2010 at 03:39:08PM -0400, Jason Eckenroth wrote:
> ...or you could just bounce the slides as jpegs. It would seriously
> be faster.

Unless the PowerPoint is actually photos then if you are going to do
this then it's better to do it as PNG rather than JPEG. JPEG
compression is designed for photos and you get artifacts with areas of
block colour and lines with hard edges.

However if you have a lot of slides it's not actually fast because:

- QLab doesn't order in the 'fuzzy' way you'd expect if you just drag
all the images on to Qlab and let it create all the video cues for
you so you end up with slides not in the numerical order you'd
expect.

- You have to manually add a stop cue for ever video cue used to
display a slide.

You will also lose any transition effects between slides.

I suspect the solution if you absolutely have to do this off a single
computer is to fire QLab via midi and leave it in the background.

Most of the best ways to do this kind of thing though kind of depend on
the show having been programmed in the tool design for theatrical media
presentation to start off with and not starting off with an asset as a
PowerPoint presentation.

-p
--
Paul Gotch
--------------------------------------------------------------------

[Rasmus Kreiner]

I just quickly looked up that my 2008 version of powerpoint has a quite extensive applescript dictionary. Maybe there would be a way to trigger next slide in this?

Best,
Rasmus

[Sten]

Hi Everyone,

I'm having some trouble with the "Minimum Time Required Between Each GO" setting.  I just had several double GOs which it turns out were caused by a faulty MIDI trigger sending out two GO commands in short succession - about 0.15 seconds apart.  However, we were set for .5 seconds in the workspace preferences so the second one should not have fired.  After some trial and error it looks like this protection doesn't work reliably.  It seems most unreliable when the cues have not been preloaded but it doesn't always work unless the setting is quite high, more than 2 seconds.  Is anyone else able to recreate this?  I've tested version 2.3.2 and 2.3.  

Thank you,

Sten

P.S.  If you do any MIDI triggering, MIDI Monitor http://www.snoize.com/MIDIMonitor/  is a fantastic tool.  

[Andy Leviss]

On Sun, Oct 17, 2010 at 2:34 AM, Sten <sten...@earthlink.net> wrote:

I'm having some trouble with the "Minimum Time Required Between Each GO" setting.  I just had several double GOs which it turns out were caused by a faulty MIDI trigger sending out two GO commands in short succession - about 0.15 seconds apart.  However, we were set for .5 seconds in the workspace preferences so the second one should not have fired.  After some trial and error it looks like this protection doesn't work reliably.  

Sten, just to confirm, are the MIDI triggers sending workspace-wide GOs, or are you triggering a specific cue list or cue? If workspace wide, this would indeed seem like a bug, but it has caught me in the past when I was trying to trigger a go to a specific cue list, and didn't realize that the double go protection doesn't apply to specific lists or cues, it only applies to workspace-wide GO triggers.

--A

==========
Andy Leviss | President | Duck's Echo Sound
646-248-6584 | @DucksEchoSound | AIM: Andrew Leviss
Your premier source for computer playback systems, custom

MIDI playback controllers, and other control products. 

Home of the Perfect Pickle, the industry's best "pocket"

sized chain hoist controller

[Patrik Wipp]

Classic; bug or feature?

Patrik Wipp

[Christopher Ashworth]

It may be presumptuous of me to call it a feature, but it is intentional.

The double go protection applies to anything that is equivalent to a person pressing the GO button. The idea was more or less to limit it to things that were clearly a human pressing the button, and not a more fancy source of automation.

On Oct 17, 2010, at 3:58 AM, Patrik Wipp wrote:

> Classic; bug or feature?

>
>> the double go protection doesn't apply to specific lists or cues, it only applies to workspace-wide GO triggers.

________________________________________________________

[mic pool]

I came across this for the first time a couple of weeks ago on a show
with lots of sound and 3 screens of video/ The operator did a double
go, claimed they hadn't, I said there was a double go protection
time set and attempted to demonstrate that it was impossible to send
two gos within 1/2 a second of each other. The demo embarrasingly
failed and I could consistently make 2 gos happen with a rapid double
press.

I have just reproduced the bug in controlled conditions in the
following way.

Put a whole lot of video cues into a group cue in fire all children at
once mode.
Duplicate the group 5 times.
reset the list and hit the go button twice rapidly
2 cues will fire

For added fun machine gun the go button 4 times to emulate a dirty
switch contact on your trigger box and watch 4 cues fire

If you increase the debounce time to a high value normal service is
resumed.

What seems to be happening is that if the load time of the next cue
exceeds the double go protection time then the queued second go press
is deemed to have occurred after the load, when in fact the 2 presses
were less than 100ms apart.

I would say this is a bug requiring an immediate fix.

Best Regards

Mic

[Christopher Ashworth]

On Oct 17, 2010, at 6:25 PM, mic pool wrote:

> I came across this for the first time a couple of weeks ago
>

> [...]

>
> I would say this is a bug requiring an immediate fix.

I'll try to recreate and will issue a fix ASAP if I can find it.

Much obliged for the report. Naturally, the sooner we hear about it, the faster we can fix it.

Best,
Chris

[Christopher Ashworth]

On Oct 17, 2010, at 6:25 PM, mic pool wrote:
>

> What seems to be happening is that if the load time of the next cue exceeds the double go protection time then the queued second go press is deemed to have occurred after the load, when in fact the 2 presses were less than 100ms apart.

Yup, this is exactly what's happening.

This may not be a trivial problem to fix, because the mouse event is being queued and literally delivered after the double-go time has elapsed. In other words, the go is, in some sense, actually being received after the protection window has elapsed.

I'll need to see if I can catch it up the chain and process it outside of the normal event processing sequence. So: something that will take some care and thought. Will try to fix as soon as I can.

Thanks very much for the helpful report. I'm doubtful I would have figured out the right conditions in which this happens without your description.

Best,
Chris

[Sten]

Mic basically covered this, but yes, this is a system wide GO command via MIDI, keystroke or mouse click.  

-Sten

[Mark Valenzuela]

>> What seems to be happening is that if the load time of the next cue exceeds the double go protection time then the queued second go press is deemed to have occurred after the load, when in fact the 2 presses were less than 100ms apart.
>
> Yup, this is exactly what's happening.

You guys have probably already thought of this, but thought I'd mention it just in case. There is a very easy work around for this bug by preloading the problem cue sequence, ie. the second cue who's load time exceeds the double go protection. If Qlab isn't in the process of loading this cue, the double GO protection will function properly.

Best,
Mark

[Christopher Ashworth]

On Oct 19, 2010, at 12:46 PM, Mark Valenzuela wrote:

>>> What seems to be happening is that if the load time of the next cue exceeds the double go protection time then the queued second go press is deemed to have occurred after the load, when in fact the 2 presses were less than 100ms apart.
>>
>> Yup, this is exactly what's happening.
>
> You guys have probably already thought of this, but thought I'd mention it just in case. There is a very easy work around for this bug by preloading the problem cue sequence, ie. the second cue who's load time exceeds the double go protection. If Qlab isn't in the process of loading this cue, the double GO protection will function properly.

True enough. Just problematic in that the double GO protection needs to really be guaranteeing what it says, under all conditions.

One idea I was thinking about was to approach this by simply adding a delay before a following sequence gets automatically pre-loaded. This could also address some other problems folks have had with the preloading of large sequences. Not yet sure if this would introduce other strangeness, though...

-C

[Sten]

I know it is a much more complicated issue, but this discussion brings me back to the idea of being able to have all cues loaded all the time. Just for argument's sake, if the head of each audio file (or edit thereof) was permanently in memory could the cues run without additional loading? Memory is cheap these days though I imagine it still might be a limitation for video.

-Sten

[Christopher Ashworth]

Yeah, I agree. This is an architecture that I'm planning on testing and, if all goes well, using.

-C

On Oct 21, 2010, at 1:36 PM, Sten wrote:

> I know it is a much more complicated issue, but this discussion brings me back to the idea of being able to have all cues loaded all the time. Just for argument's sake, if the head of each audio file (or edit thereof) was permanently in memory could the cues run without additional loading? Memory is cheap these days though I imagine it still might be a limitation for video.
>
> -Sten

________________________________________________________

[Andy Leviss]

On Thu, Oct 21, 2010 at 1:39 PM, Christopher Ashworth
<ch...@figure53.com> wrote:
> Yeah, I agree.  This is an architecture that I'm planning on testing and, if all goes well, using.

The problem I see is that you can never underestimate the scale of the
show. As one extreme example, I don't know the cue count (Justin, are
you here?), but "The Ride", a mobile show here in NYC, has so many
audio and video cues that opening the workspace takes somewhere in the
neighborhood of *ten minutes*. Just to load the workspace! I shudder
thinking what might happen trying to keep that many cues even
partially pre-loaded.

--A

[Christopher Ashworth]

On Oct 21, 2010, at 2:18 PM, Andy Leviss wrote:

> On Thu, Oct 21, 2010 at 1:39 PM, Christopher Ashworth
> <ch...@figure53.com> wrote:
>> Yeah, I agree. This is an architecture that I'm planning on testing and, if all goes well, using.
>
> The problem I see is that you can never underestimate the scale of the
> show. As one extreme example, I don't know the cue count (Justin, are
> you here?), but "The Ride", a mobile show here in NYC, has so many
> audio and video cues that opening the workspace takes somewhere in the
> neighborhood of *ten minutes*. Just to load the workspace! I shudder
> thinking what might happen trying to keep that many cues even
> partially pre-loaded.

Understood, although I think there are some ways to address this. Audio is probably currently over-buffered, and a ton of audio should be bufferable in small sizes. Video we're going to try to attack in a slightly different way.

-C

[Andy Leviss]

On Thu, Oct 21, 2010 at 2:23 PM, Christopher Ashworth
<ch...@figure53.com> wrote:
> Understood, although I think there are some ways to address this.  Audio is probably currently over-buffered, and a ton of audio should be bufferable in small sizes.  Video we're going to try to attack in a slightly different way.

Cool, figured you were on it, just wanted to throw it out there. I've
seen some big shows, but that set some new records for me :-)

But that's why you program these big, complicated beasties, and I
program itty bitty little MCUs!

--A