Pre vs Post wait theory

[Bruno Carneiro]

Hi qlabers! I'm putting together some complex shows here in São Paulo BR and I've been talking to myself about the concepts of pre and post wait. The way I see it, the series/post-wait and parallel/pre-wait metaphor is perfect. I find myself always going for group cues with pre-wait times to create a "timeline", it just feels more intuitive to me than post-wait cues that will affect one another if I need to change times. But I've been wondering if post-wait cues would reduce the load on the computer, particularly with video cues.

What do you think about it? Would you care to elaborate on the pros and cons?

Thanks,

Bruno

[Joshua Langman]

I habitually build cue sequences as start-all groups using pre-waits unless there is a specific reason to build them some other way.

I do not believe it makes any difference in terms of the processing load on the computer.

I'm attaching a screen shot and a document that codify some arbitrary guidelines for programming in a way that I believe makes it easiest for the designer and op to see what's going on.

Again, these guidelines have no claim to being more correct than other ways of working, but they do seem to be widely used by designers I've worked with, if rarely explicitly articulated in this way.

Josh

[Sam Kusnetz]

Hello folks

Speaking with my Figure 53 hat on, there is one essential distinction between a sequence of cues in a start-first Group with continues and post-waits and a sequence of cues in a start-all Group with pre-waits, and this is it: cues are “active” while their pre-wait is elapsing.

To make the start-first Group and the start-all Group behave exactly the same way, you also need to load all the cues within the start-first Group before running it. One way to do that would be to set all the child cues to auto load.

So. They can be made to be exactly equivalent, but by default they are only *almost* exactly equivalent.

Now, speaking with my Sound Designer hat on, I will say that don’t explicitly disagree with any of Josh's guidelines, and in fact most of the time, I build shows according to similar principles.

But also, I think it’s only fair to say that some of these guidelines require some context to really feel just right. For example, item 5, “fade outs should target the numbered Group cue, rather than the [child] cues themselves, to facilitate revisions.” In my opinion, that makes it rather harder to facilitate revisions, since among the most likely revisions I encounter when I’m fading out a batch of cues at once is to use different fade times or fade shapes for different cues.

I’m not trying to quarrel, only to reinforce the notion that the reason QLab offers different ways to do the same thing is so that you can build exactly what you need.

Best

Sam

—

Sam Kusnetz | Figure 53

s...@figure53.com

[Mike Post]

Jumping in the middle here - apologies.  At the risk of being redundant and just to clarify one thing…

My perception has been that a ‘start all children with prewaits’ group doesn’t really hit the CPU in a bad way, but does have the advantage of loading all content in the group into memory when the group executes instead of waiting for each cue to finish a postwait before loading the next file.  I’ve used this to fix odd little lags in sequences on smaller machines.

Is this true?

Mike Post

mdp...@mac.com

http://mdpostdesign.com

(601) 307-8657

-- 
-- 
Change your preferences or unsubscribe here: 
http://groups.google.com/group/qlab
 
Follow Figure 53 on Twitter: http://twitter.com/Figure53
--- 
You received this message because you are subscribed to the Google Groups "QLab" group.
To unsubscribe from this group and stop receiving emails from it, send an email to qlab+uns...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/qlab/etPan.57ea9f8a.3a9515db.e907%40figure53.com.
For more options, visit https://groups.google.com/d/optout.

[Anthony Narciso]

Every single show of mine is programed with "Fire All At Once". Basically every cue is in one of those groups, even if its a single file, so I have the option to add more things quickly. The one exception to this rule is a preshow playlist or video slideshow. Those are all programmed as "Fire and Go to Next Cue" because it is more efficient to use autofollows on those. 

My philosophy is use whatever option is less keystrokes/mouse clicks and less time math. So if you were going to use auto-continues just use a fire all at once with pre-wait because it  saves you from having to click the auto-continue arrow and doing the math for when all of those auto-continues must be taken. Pre-waits are so much easier simply because they can be timed off of the start of the cue rather than when a preceding cue in the group happens.  If I need something to be an autofollow then it makes sense to use the "fire and go to next" because all you need to do is click the auto-follow arrow. 

[sam kusnetz]

> On Sep 27, 2016, at 1:28 PM, Mike Post <mdpost...@gmail.com> wrote:
>
> My perception has been that a ‘start all children with prewaits’ group doesn’t really hit the CPU in a bad way, but does have the advantage of loading all content in the group into memory when the group executes instead of waiting for each cue to finish a postwait before loading the next file. I’ve used this to fix odd little lags in sequences on smaller machines.
>
> Is this true?

Hello Mike

Yep, that's the notion I was getting at. You are correct!

Sam

--
Sam Kusnetz | Figure 53
http://qlab.tips | http://qlab.tv
(mobile)

[Bradford Chapin]

I too agree with Josh's guidelines. I switched at some point from post wait land to start all groups with pre waits. I think my brain was trained in the SFX days, but anyone who's on the fence, you can change! I think the greatest benefits are the visual layout (it just looks clearer,) and no more "auto-continue hell". When I was a post wait-er, it was easier to make programming mistakes by mis-clicking the little continue arrow, copy-pasting an arrow to a new cue that didn't need one, et cetera.

+1 for Sam's note on item 5 though. I also tend to create a fade cue for each audio cue. The ability to adjust timings of individual files in the group beats out having to re-target if the content changes.

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

Follow Figure 53 on Twitter: http://twitter.com/Figure53
---
You received this message because you are subscribed to the Google Groups "QLab" group.

To unsubscribe from this group and stop receiving emails from it, send an email to qlab+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/qlab/FFC88993-2E41-4DAB-930A-CF6D1ED5E309%40figure53.com.

[Bruno Carneiro]

Thanks Josh! Item no.6 was instantly helpful to me as I was building a show with video cues. I took a look at your screenshot and it looks to me as if you are using different syntax for group cues no.23 and no.24. For group cue no.23 you used a start first with auto-continue and pre waits, and for group no.24 you used a start all with pre waits. Was there a special reason for that? 

There's another situation I would like to put forward as well. As Sam and Mike pointed out, firing a start-all group loads all the content into the memory. Let's say I have a computer with not enough RAM, could a group with a lot of content cues cause problems? And if that is true, could a start-first group with auto-continues and post waits be more adequate? I could build a project to illustrate, but I don't have my computer with me. 

I would also add another guideline that seems really helpful to me: I always order the cues inside a start-all group according to their pre-wait time. It makes it easier for me to see what's happening, especially with large groups! 

Bruno 

[Rich Walsh]

Pretty sure loading a cue doesn’t load the content into RAM: just enough of it to allow for the variable time it will take to be able to start streaming from disk. Also, are you really running into machines with less than 4GB of RAM in them? That’s a lot of content: like a whole DVD…

To be honest I don’t really understand why you would ever want to not load a cue before firing it? If you don’t load it, the latency of it firing is unpredictable – as I know from experience in rehearsals. Why would you want that in a show? Of course you need to manage the loading of the next cue so it doesn’t happen at an inconvenient moment and cause a glitch, but that was true in QLab 2 and easily managed (pre-load cue 3 at the end of cue 1, not when cue 2 goes – if cue 3 takes a while to load and makes cue 2 fall over).

Rich

[Bruno Carneiro]

I see... thanks for the input Rich! And great template btw!