Loading to time on a cue with several unlimited loops and devamps

[Janne Sivonen]

Hi list!
Problem: How can I load to time or start a cue past a vamp/loop that is set to unlimited looping?

Situation: We are running backtracks on qlab for a non-Disney version of the Jungle Book. Up to 16 stereo tracks in "start all children simultaneously" groups. Several songs go into vamps/loops that we need to manually vamp out of with a pile of devamp ques, and there is some places within the same song where it goes into a vamp a second time.
So how can we start the playback after the first loop to test programming? / use as a rehearsal point? It is very tedious to sit trough minutes of music just to check one change in looping points.
I understand that "load to time" has a problem because of the indefinitely looping part that's waiting for a devamp, but it is a huge pain in the ass for us right now just logistically.

Any ideas/thoughts?
My idea would be to set up "rehearsal points" in the sound cues and "load to rehearsal point nr X" on the sound cue, not being dependent on anything that logically happens before that point in time. Rehearsal points could be based on existing markers/slices.

Best,
Janne

[Christopher Ashworth]

Hi Janne,

A few ideas:

On Aug 29, 2013, at 8:44 PM, Janne Sivonen <janne....@svenskateatern.fi> wrote:

> Hi list!
> Problem: How can I load to time or start a cue past a vamp/loop that is set to unlimited looping?

Perhaps try setting the loop to something finite? If it is any finite number, load-to-time will be able to load past it.

Alternately, you can now click anywhere in the waveform and jump to that position in the file, even if there are infinite loops earlier in the file. This lets you jump ahead in that single file, although wouldn't work for a full cue sequence.

-C

[Janne Sivonen]

Chris,
thanks for your answer.
While this works as a workaround I hope that you keep this scenario in mind while designing the new slider/move to time functionality that people are asking about.

Janne Sivonen
+358 503716443
janne....@svenskateatern.fi

> --
> --
> 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.
> For more options, visit https://groups.google.com/groups/opt_out.

[Chris Ashworth]

Hi Janne,

Can you describe your thinking here in more detail? You say "workaround" but to me that word implies something isn't working correctly. Surely it is both important and correct for a finite amount of time to not bypass an infinitely looping slice?

(mobile)

[Joshua Langman]

I would disagree. I think in general, for loading purposes ("load to time" slider, "active cues" sliders, and load cues), an infinitely looping slice should be treated as though it only plays once. But this is a tough call, and I can imagine scenarios in which this wouldn't be the desired behavior.

[Christopher Ashworth]

On Aug 30, 2013, at 11:07 AM, Joshua Langman <jlangma...@gmail.com> wrote:

> I would disagree. I think in general, for loading purposes ("load to time" slider, "active cues" sliders, and load cues), an infinitely looping slice should be treated as though it only plays once. But this is a tough call, and I can imagine scenarios in which this wouldn't be the desired behavior.

A 30 second loop that plays forever, when told to load to time "40 seconds", should not play at all, instead of play from the time it will actually be playing from if you let it play for 40 seconds?

[Joshua Langman]

Yes, that's right. At least that would be my preference. But as I said, I expect others to disagree.

[Joshua Langman]

I should clarify that I'm talking about infinitely looping slices. Cues where the entire file is set to loop indefinitely (and is not sliced) would behave as they do currently.

[Jeremy Lee]

I don't agree with this. Many a rain storm sequence consists of a dozen loops punctuated with lots of smaller events. I wouldn't want the loops to run out when they're set to infinite loop and I use a load to time slider for a sequence...

On Aug 30, 2013, at 11:07 AM, Joshua Langman <jlangma...@gmail.com> wrote:

> I would disagree. I think in general, for loading purposes ("load to time" slider, "active cues" sliders, and load cues), an infinitely looping slice should be treated as though it only plays once. But this is a tough call, and I can imagine scenarios in which this wouldn't be the desired behavior.

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

[Janne Sivonen]

Hi Chris,

> Can you describe your thinking here in more detail? You say "workaround" but to me that word implies something isn't working correctly. Surely it is both important and correct for a finite amount of time to not bypass an infinitely looping slice?

I fully agree with the logic behind the current behaviour, but I am lacking a tool to start playback in the middle of a audio cue, based on the time of the reference file, not the "logical playback time" of Qlab.
I think that the word "rehearsal point" describes my intention. For example a Load cue with the parameter "load to slice n. 4 of the cue" which would start the playback from slice n.4 even if slices 1-4 were all set to loop infinitely.

While setting the loop amount to somehing finite gives the possibility to load through loops, it lacks the ability that most of us who are working with music as playback material in rehearsals wish for. "Play from drumroll after the loop please" is now difficult even if I know exactly the second in the referenced audio file where I should start the playback.
Anybody else who could use a system of "rehearsal points"?

Best, Janne

[Daniel Perelstein]

Yes, I had a strong interest in "rehearsal points" last spring on qlab 2. 

Designed a show where we spent a full two weeks teching a single very complex sequence (which, once teched, we changed and thus re-teched daily in response to previews). It hinged on ten waves breaking, synced with lights and hydraulic movement of a boat on stage (operated manually). 

The waves were on top of an already-complex sound score that changed throughout the scene (ambient water, engines fading in and out and changing level and routing, roaring, etc). It was also a very loud sequence. It also included recalling a bunch of scenes on an M7 via midi. 

To get to any point (say, to fast forward to wave eight in the sequence) required a good 2 minutes or so of loading-to-time of every cue in the sequence and keeping track of which layers would be faded in and out before our "rehearsal point" and thus could be skipped altogether. Each "load-to-time" could land us at very loud moments without warning, and because this went on for days on end, everyone in the room was pretty fried. 

In any case, at the time, I very much wanted the ability to "bookmark" different playback states for rehearsal purposes, as we wasted a ton of time, all-told, navigating to the same place over and over and over again. 

Dan

[Sam Kusnetz]

Joshua Langman wrote:
> To get to any point (say, to fast forward to wave eight in the
> sequence) required a good 2 minutes or so of loading-to-time of every
> cue in the sequence and keeping track of which layers would be faded
> in and out before our "rehearsal point" and thus could be skipped
> altogether. Each "load-to-time" could land us at very loud moments
> without warning, and because this went on for days on end, everyone in
> the room was pretty fried.
>
> In any case, at the time, I very much wanted the ability to "bookmark"
> different playback states for rehearsal purposes, as we wasted a ton
> of time, all-told, navigating to the same place over and over and over
> again.
> Dan

The way I manage sequences like this is by using Group cues set to
"Start All Children Simultaneously" wherever possible, with child cues
timed out using prewaits. Since the cues contained within such a group
are considered a single sequence, when I Load-To-Time on the Group cue,
all the child cues load in sync.

Obviously it doesn't work for every situation, but I've found it's a
good mindset to try when faced with sequences like this.

Cheerio
Sam
--
Sam Kusnetz
QLab Support Operative
s...@figure53.com

[Daniel Perelstein]

Yep, had many mini-sequences in exactly the syntax you describe. 

There were probably a hundred or so called cues within the sequence I described, so to get into standby for wave 6, for instance, required loading to time for, for instance, some 40-or-so previous groups.

In any case, I'm pretty confident my syntax was reasonable, and my workflow was too, but I just felt like there was a qlab function that could be developed to expedite things. 

That all said, I decided not to request it at the time, as I made it through and have been in hundreds of techs and this was the first time I felt a distinct need for this. Just brought it up now because it was requested by someone else who asked if others had seen the need ...

Hope this helps!

Dan

[Sam Kusnetz]

> There were probably a hundred or so called cues within the sequence I
> described, so to get into standby for wave 6, for instance, required
> loading to time for, for instance, some 40-or-so previous groups.

That sounds intense. I suspect an AppleScript solution, though probably
time-consuming to create, would probably be the way to achieve something
like this in the future... something like "load group a to time x, group
b to time y, group c to time z" etc.

But it's certainly food for thought and situations like yours provide a
good example of some of the edge cases of how QLab works and how it's used.

Thanks for your input!

[Rich Walsh]

On 1 Sep 2013, at 20:33, Sam Kusnetz <s...@figure53.com> wrote:

>> There were probably a hundred or so called cues within the sequence I
>> described, so to get into standby for wave 6, for instance, required
>> loading to time for, for instance, some 40-or-so previous groups.
>
> That sounds intense. I suspect an AppleScript solution

http://wiki.figure53.com/QLab+Scripts+and+Macros#x-Loading-Jump%20into%20a%20string%20of%20cues

Wrote it after a show in 2010, used it at the beginning of August to do exactly what is described: standby a cue as if all the other cues have been fired in sequence.

Rich

[Daniel Perelstein]

Aaah. Very interesting, Rich!

I had also thought of programming a separate cuelist with sequences of start and loads to get me in standby for each of the ten waves, but didn't because it was also time-consuming.

Anyways, if I once again find myself in this boat (pun intended), I suspect I'll give your script a shot!

In the meantime, perhaps this represents something useful for development when thinking about the OPs question, although I understand mine is likewise an edge case, and you guys certainly have a ton on your plate at the moment!

Dan

[Jeremy Lee]

If you repeated the same section that many times, you might have been able to build a "rehearsal point" group cue with various load to time cues and triggering of fades.  It might have taken a bit to get set up, but it might have saved you hours in the long run.  I've never tried it like that, but I think it would work...

On Sep 1, 2013, at 3:29 PM, Daniel Perelstein <dpere...@gmail.com> wrote:

Yep, had many mini-sequences in exactly the syntax you describe. 

There were probably a hundred or so called cues within the sequence I described, so to get into standby for wave 6, for instance, required loading to time for, for instance, some 40-or-so previous groups.

In any case, I'm pretty confident my syntax was reasonable, and my workflow was too, but I just felt like there was a qlab function that could be developed to expedite things. 

That all said, I decided not to request it at the time, as I made it through and have been in hundreds of techs and this was the first time I felt a distinct need for this. Just brought it up now because it was requested by someone else who asked if others had seen the need ...

Hope this helps!

Dan

On Sunday, September 1, 2013, Sam Kusnetz wrote:

Joshua Langman wrote:

To get to any point (say, to fast forward to wave eight in the sequence) required a good 2 minutes or so of loading-to-time of every cue in the sequence and keeping track of which layers would be faded in and out before our "rehearsal point" and thus could be skipped altogether. Each "load-to-time" could land us at very loud moments without warning, and because this went on for days on end, everyone in the room was pretty fried.

In any case, at the time, I very much wanted the ability to "bookmark" different playback states for rehearsal purposes, as we wasted a ton of time, all-told, navigating to the same place over and over and over again.
Dan

The way I manage sequences like this is by using Group cues set to "Start All Children Simultaneously" wherever possible, with child cues timed out using prewaits. Since the cues contained within such a group are considered a single sequence, when I Load-To-Time on the Group cue, all the child cues load in sync.

Obviously it doesn't work for every situation, but I've found it's a good mindset to try when faced with sequences like this.

Cheerio
Sam
--
Sam Kusnetz
QLab Support Operative
s...@figure53.com

-- 

[Kelly Schmidt]

Is there no Applescript commands to "Get Current Time" and "Set Applescript script"?

If there were, theoretically you could create a script that

• Gets a list of all active cues
• Gets their current playback positions
• Gets the currently selected cue
• Creates a new script
• Sets the new script script to ...
• Load each cue to the captured playback position
• Start each cue
• Select the captured selected cue

I tried to quick write one up, but found that I couldn't get the current time of a cue or set the a Script's script

[Rich Walsh]

There isn't an AppleScript hook to get elapsed time, other than a kludge via Devamp Cues (https://groups.google.com/forum/#!topic/qlab/bXoo6OgvhbE). This variable is accessible via OSC though, but I don't know if there is a way of constructing an OSC Cue to act on the information obtained as a result of a query. There must be someone on this list who knows what OSC does…

As for the second, why bother making another Script Cue when the original script can just do this work itself? It could store variables in itself and then choose whether to use or capture them based on whether any other cues are active. Neater would be to make a Load Cue for each cue that needs loading and wrap all that up in a Group Cue.

Anyway, none of this actually addresses the OP's real problem: the fact you can't load a cue past an infintely-looping slice.

Rich

[Kelly Schmidt]

It's true. Load (cue "x") to time falls into the infinite loop

An alternative, messier option would be to set the StartTime to the recalled position, start the cue, then restore the StartTime

The new ScriptCue then becomes the bookmark by the way. That's the theory. It's script stores the cues/times. 

Would it be possible to add more hooks? There are a number that are in the OSC API but aren't in the AppleScript API

[Christopher Ashworth]

On Sep 4, 2013, at 11:25 AM, Kelly Schmidt <kellys...@gmail.com> wrote:
>
> Would it be possible to add more hooks? There are a number that are in the OSC API but aren't in the AppleScript API

Yes, I'd like to try to keep filling out both sets of hooks. As much as I hate AppleScript, it's extremely powerful in ways that OSC can't be without a lot of extra external work.

-C