Skip to next slice?

[Stephen Harrison]

I'm building a show for a musical and I've just come up against something that I assumed would be straightforward, yet is so far eluding me.

There are vamps in tracks, and that's easy to slice and de-vamp. But there are also fermatas, where I need to be able to optionally skip ahead to the next slice on a cue.

Splitting the track into multiple cues, with auto-follow, sort of works, but setting the in and out points to the same time results in an audible glitch on the transition. But that doesn't solve the workflow issue of optional cues to skip ahead.

I'd really like to keep the audio in a single cue, as that will sound best when played through with no skips. But I haven't yet found a way to Goto/skip to next slice.

Scripting might also be a non-starter, as there doesn't seem to be much for slices in the script directory.

Any thoughts or suggestions?

[harry.jame...@gmail.com]

Hiya,

To clarify - you want to, at any point within a slice, skip its remaining duration? 

If the slice indices are pretty set-in-stone you could try a /cue/{cue_number}/sliceMarker/{index}/playCount {play_count} OSC message targeting the specific slice and setting its play count to 0, e.g. /cue/1/sliceMarker/1/playCount 0

This should probably go in a group with a second message that restores its intended play count after a pre-wait; screenshot attached.

OSC message docs: https://qlab.app/docs/v5/scripting/osc-dictionary-v5/#cuecue_numberslicemarkerindexplaycount-play_count

[harry.jame...@gmail.com]

Apologies for the double-post - probably worth adding an addendum that this is (maybe obviously) a v5-only solution.

[Stephen Harrison]

According to the documentation, this should also work on Qlab 4:

/cue/{cue_number}/sliceMarker/{index}/playCount {play_count}

Set the play count of slice index of the specified cue. play_count can be any positive whole number, or -1to set the slice to infinite loop.

Except that setting a value of 0 has the same effect as -1 (sets it to infinite). Maybe a bug? A v4 solution would certainly be preferable atm…

[harry.jame...@gmail.com]

Slices with 0 play counts is a new feature in v5, sadly.

[Stephen Harrison]

Yes, good point.

So the technique works in theory, but it's really buggy. The playhead moves as it should and sometimes the correct audio plays, but sometimes it doesn't and keeps playing the audio from the previous slice (out of sync with the playhead).

There is also no need for the second OSC cue to reset the slices. It seems that changes made to the playCount with OSC are thrown away when the target cue is run again, being reset back to the original slice values. Not sure if that's another bug or intentional behaviour?

[Taylor Glad]

Splitting the track into multiple cues, with auto-follow, sort of works, but setting the in and out points to the same time results in an audible glitch on the transition. But that doesn't solve the workflow issue of optional cues to skip ahead.

 Are you loading your cues?

This has always made seamless transitions for me between clips.

And for the fermatas (I assume you are looping a section of a track) I would just make a different audio cue that stops the other cue when it starts. (Either with the Triggers tab, or having a stop cue fire with it)

The most common example I see of this is looping a drumroll for as long as you want, but immediately cutting to the crash at any given moment.

[Chris Ashworth]

To jump in on one technical question:

QLab does not guarantee seamless playback between separate cues, so even pre-loading a cue will leave open the possibility that there will be a brief dropout when picking up the next cue.

I was curious to see if someone would come up with a way to do this but for what it’s worth I’m not aware of one off the top of my head.

-C

[micpool]

Re Chris’s point about dropouts between cues; older members of the group who started on magnetic tape based playback know the advantage of a 45 degree splice on an edit .On ¼ inch tape at 15 i.p.s the effective crossfade of 0.015s masked a multitude of timing and phase anomalies at the edit point. Using a 0.015s fade  and stop at devamps instead of a stop previous, and overlapping autofollowing consecutive sections by a similar amount, may give audibly  better transitions in a variety of circumstances.

Changing a playing slice to a playcount of 0 will not achieve a jump to the next slice, but will produce the anomaly noted by Stephen, that the playback cursor is not in sync with the audio being output.

In general, the only way to move around a playing cue is to pause, load to a new time and resume playback, which is obviously not seamless, so as Chris said I don’t think there is a solution that doesn’t involve splitting the audio file into multiple cues.

Finally, I can’t replicate Stephen’s observation that changes to slice marker playcounts are a live parameter and reset after a cue is stopped. They edit like a normal parameter  and persist from that point, unless the workspace is closed without saving.

Mic

[harry.jame...@gmail.com]

Interesting that neither of you can replicate the behaviour I'm seeing with the OSC method - my playhead doesn't go out of sync either. Updates briefly to show the new cue timing, then back to the original once the reset is fired.

Screen recording attached for interest, because it's definitely doing what's described on my end - but trying this again today I'm hearing zero-crossing-point clicks with this too (which, on reflection, makes perfect sense) - my source material must've been hiding them the other day.

Agreed that a crossfade would be the best way to do this with no audible impact. 

Screen recording: https://we.tl/t-MW4wV4E5DF 

[micpool]

Harry,
Your screen recording has no audio so it's difficult to hear what's going on.

Yesterday I could  not, regardless of what I did, get this to behave as you described, but today having replicated your workspace, it works every time and remains in sync. It works regardless of how the network cue is triggered, or if the second network cue changes the slice play count back  straight away. I can't think of any difference between what I was doing yesterday or today, but didn't save that workspace or  screen record it, but  probably this indicates that it's not 100 percent  reliable as a method, and I can't see it has much advantage over having things as separate cues.

However, to show it working (with audio) Here's a screen recording of a silent fermata (GP ) achieved with an integrated fade using a play count 0 to exit an infinite loop.

Mic

[micpool]

OK, I've replicated the way I had it not working yesterday yesterday

If there is a  slice play count of 1 and the play count   is set  to 0 while playing that slice, play continues as normal and the cursor loses sync.

If the play count is set to 0 and immediately reset to 1 then it works in the way Harry described, but I think this is just forcing a recalculation of times in a similar  way that pause/load to time/resume would do as the glitches seem to be a result of the slice recalculation rather than a zero crossing problem

All three cases recorded in the screen recording attached.

I still think this is probably not a good way to do this, but at least I have shown that everyone's observations  were valid!

Mic

[Stephen Harrison]

I've been a bit slow following up on this, as I wanted to get to a working solution (for now) before replying.

First, to clarify a few points from my OP that seem to have got lost in the general discussion:

1. There are no vamps. The music plays with a series of long, sustained chords before progressing to the next part of the music. Depending on the pace of the actors the track will either play as-is, or a cue is triggered to jump ahead.

2. There are no G.P.s, or silence. Left to play through, there is continuous music throughout, which is why the slight glitches from butting up one cue against another (with the same out/in point) didn't work. In other cases where there is a pause, it is simple to split the track into separate cues and run them as needed.

3. These skip cues are optional, as so may not be needed, depending on the pace of the actors.

This is how I have made it work (a little Heath-Robinson, but it gets there):

If I just run the first cue then it will play all the way through, and advance the playhead when the timeline reaches the next slice.

If I manually run one of the point cues, that starts a new audio cue, set to start at a slice point and play through to the end. The optional group cues have a trigger to fade & stop peers with a 0.2s fade. This smooths out the audio and stops all remaining neetwork cues in the previous group.

While this works, it is obviously a bit fiddly and does not scale well at all.

Chris, I’m guessing from your earlier comment that this isn’t something that has been considered as a feature (rather than considered and dismissed). It’s clearly not a common requirement (we’ve made it to v5 without it), but I’ve found myself needing to do this on several numbers in this musical, so I feel a “jump to slice” cue is worthy of future consideration.

Stephen

[micpool]

I think that  there is always going to be a flaw with any method that does not utilise some sort of crossfade.

If a slice is set to 0 before the audio is played it is skipped perfectly(You can check this with a 100Hz sine wave with slices at 1 sec intervals.=)

Even if it was possible to do all the timings that would have to be recalculated, if a currently playing audio file, or a slice of that file had its times edited, without introducing any audible  artefacts, you would still be left with one major problem.

Unless your music was recorded in an anechoic chamber, or with synthesisers or samplers using a zero release time, there is going to be some decay or reverberation from the chord in the  previous paying slice overlapping with the chord in the  slice following,  If you skip a slice then the previous chord will cut abruptly and the chord in the new slice  will start with   the decay or reverberation of a slice containing a chord that has not actually been played yet.  A very short crossfade would will render these discontinuities inaudible.

The example screen recording uses a difficult case, solo bass piano notes, and introduces a .05s crossfade either side of the edit (which will reduce the length of each note by .05 secs) You can skip any slice(s) and the transition is seamless. (it also uses a very short chamber hall reverb to restore the decay of the previous chord

I think this is the best solution for critical audio which exposes the edit points

Mic