Devamping Early

[Anthony Narciso]

Hello! 

I'm working on a production right now where devamps are consistently being called too early. Does anyone have a script or some kind of solution so that if a devamp is taken too early the slice count is temporarily set to 1 so the music continues on and ignores the vamp entirely?

[Chris Ashworth]

Hi Anthony,

Thanks for your question. 

I may be misunderstanding your description, as to me it sounds like you are asking for a script that mimics a devamp.  (Setting a slice count to 1 is what a devamp does, to leave the vamped section.)

Perhaps you mean you would like the cue to ignore the devamp command until a given time?

If you mean that you would like the devamp to be ignored for a minimum amount of time, I can imagine approaching that without scripting, so that the devamp cue is not armed (using an arm cue) until a minimum amount of time has passed…

There is also the works-space wide double-go protection, which might conceivably be helpful depending on how rapidly your operator is jumping the cue.

-C

[Philip Glenn]

I’m not sure what you’re asking. You mean the vamp is being fired before the slice has begun?

Philip

On Jun 23, 2021, at 2:08 PM, Anthony Narciso <anthonynar...@gmail.com> wrote:

Hello! 

I'm working on a production right now where devamps are consistently being called too early. Does anyone have a script or some kind of solution so that if a devamp is taken too early the slice count is temporarily set to 1 so the music continues on and ignores the vamp entirely?

--
Contact support anytime: sup...@figure53.com
Follow QLab on Twitter: https://twitter.com/QLabApp
User Group Code of Conduct: https://qlab.app/code-of-conduct/
---
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/3261b1f0-f2e8-43cc-9cbb-778d3d104bc3n%40googlegroups.com.

[Anthony Narciso]

Thanks so much for responding! 

What's happening is the operator (or in some cases the actors speed) is inconsistent. If the actors blow through their dialogue or the operator is trigger happy,  I need to essentially cancel the vamp that we aren't in yet. I guess in a way that means ignore the devamp until we are actually in a vamp. The arm/disarm idea could work. I'll try and wrap my brain around what that would look like. 

[Harry Halliday]

If I’m understanding this correctly, you basically want the effect of a devamp to be queued up until it would have an effect, if fired before the cue is in a slice that loops?

If so, here’s my solution: 

Two devamp cues in a “Start first child and go to next cue” group. The first one should have the “Start next cue when target reaches the end of current slice” box ticked, and the second should just be a standard “devamp currently looping slice” devamp cue. 

This will mean that whenever the group is fired, the looped slice will either be devamped, or the devamp will be fired (by the first devamp cue) as soon as it would have an effect.

Hopefully this makes sense; it’s a bit difficult to explain. Here’s a screenshot that hopefully makes it a bit clearer: 

Harry

[Chris Ashworth]

(I just wanted to note for the record that we have an issue tracking the idea of being able to name or otherwise identify slices so that QLab could load to a specific slice or devamp a specific slice; I’ve added a link to this Google Group discussion to that issue.)

-C

[micpool]

I think this is the only way to do this reliably, 

When Part 1 is started
the playcount of the vamp slice is set to 1 
the post wait of a network cue that sets the vamp slice to inf is set to the time of the slice marker at the beginning of the vamp slice

When Part 2 is started

the cue devamps

the vamp slice is set back to a playcount of 1

the network cue that sets the vamp slice to infinite is stopped

So if cue 2 is taken before the vamp slice then the vamp slice never gets set to infinity, and the devamp doesn't do anything because the section before the vamp slice has a playcount of 1

If the vamp slice is reached before cue 2 is taken (intended behaviour) then the vamp slice is set to a playcount of infinity then, when cue is taken, the cue devamps in the normal way the vamp slice is reset to a playcount of 1, and the stop cue doesn't do anything because cue y has already finished its business.

Example workspace and screen recording attached

Mic

[micpool]

Harry's solution is much simpler than mine, and works just  as well so I'd use that one!

Mic

[micpool]

Although Harry's version doesn't seem to work every time. I've attached a screen recording of it failing  and a copy  and the workspace. Perhaps it just needs a small pre wait somewhere to fix it?

I can't make my version misbehave.

Perhaps someone else could test both versions and see if they can replicate?

Mic

[micpool]

I think Harry's version will work correctly every time  with a .1 sec pre wait on  the second devamp cue

[Harry Halliday]

Interesting - I was thinking a pre-wait might break it in the other direction, given that the second devamp doesn’t fire until the end of the looped slice if it’s cued ‘correctly'. I think there’s something going on with the timing that I don’t understand - to be honest I was a bit surprised this method worked in the first place for the same reason, and am now more surprised that it broke when entering the looped slice rather than exiting it. Did you manage to work out what was going on that caused it to fail?

Harry

[Harry Halliday]

Oh, I’ve just realised why that was stupid - the second devamp does nothing when you fire the group while inside the looping slice.

[micpool]

On Thursday, June 24, 2021 at 1:44:46 AM UTC+1 harry.jame...@gmail.com wrote:

Oh, I’ve just realised why that was stupid - the second devamp does nothing when you fire the group while inside the looping slice.

I don't think that's necessarily a problem Harry. The 0.1s pre wait on the second devamp may well fix it, but it needs testing a lot because the original does   seem to be edge case sensitive.  It hardly failed at all when I had the waveform in a pop out inspector, but when I closed that it failed more often which suggests that the event timing had changed subtly. Put the 0.1s pre wait in and see if you can break it either inside or before the vamp.

Mic

[Harry Halliday]

Sorry, Mic - the stupidity I was referring to was my own, with regards to the question about why it won’t fail at the end with the pre-wait - the first devamp cue is the only one required when it’s being cued ‘correctly’, because it will devamp the loop as well as fire the next cue (which now won’t have anything to devamp). I clarified this to myself but just disarming the second devamp cue and trying to cue it within the vamp, which clearly works as intended.

That means that the pre-wait on the second one can be as long as we want, provided it’s not longer than the looping slice.

So I think it’s probably safest to use a 0.5s pre-wait to ensure that you’re well into the loop before devamping - there are obviously some issues if you have two loops in a row, but I think that the version without the pre-wait would’ve suffered the same issues.

What I’m finding more interesting is what it is that’s causing it to fail - I think it might have something to do with the start time on the audio cue in your sample workspace, as fiddling with this value changes the behaviour pretty reliably - and like you say, having the waveform in view also seems to have some impact. One of those timing precision things that isn’t worth losing sleep over, I guess...

[micpool]

I think the only thing that would explain the failure when entering the vamp slice would be the second devamp triggering milliseconds before the slice. The fact that the start time for the audio cue , affects the likelihood of an incorrect devamp, which I also observed, probably means that there is a small error on the  post wait time of the first devamp when QLab calculates it on the fly when the first devamp is triggered.

Perhaps a 0.01s  pre wait  on the first devamp and .3 on the second, would be the optimum solution. 0.01s prewaits are often a good method for resolving timing issues and for forcing events to occur in the desired order. The combination of the 0.01s and the execution time of the Pre wait mechanism often resolves timimg problems e.g a start cue in a timeline group that restarts the group  can often fail to trigger if the group cue thinks it is still running. 0.01s of prewait on the group often resolves this, although I tend to use .1s  in cases where it makes no difference.

 As you say this would cause difficulties with 2 consecutive vamp slices, but would work fine with multiple vamps, as long as they had slices with a playcount of 1 between them. 

And no apology necessary,  I knew what you were referring to!

Mic

[micpool]

Any pre wait on the first devamp cue doesn't fix anything, and looking at it  again there is no real reason why it should!

A 0.001 prewait on the second devamp cue makes it work most of the time, 0.01 all the time, as far as I can see, so 0.05 should be a safe  value.

With a margin of x 50   0.5s should be bomb proof!

I think this is now a simple and really good method. It will work with multiple looping vamp sections  as long as they are separated by a slice with a play count of 1.

I've attached a workspace if anyone else wants to test it.

Mic

[Anthony Narciso]

Thank you so much for the help everyone! This has been a good solution for the show. 

Looking forward to eventually being able to ID slices as well!