Qlab Unpause issue

[jonnybrandon]

Hi all.

 

Am having a problem with a 'Play' cue in Qlab. Hoping somebody here might know a solution.

 

We are running Qlab on a Macbook Pro with audio output through minijack to two DI's.

 

In this particular sequence we are playing a track at 0db, 'Pause' cue for pausing, then 'Play' cue for resuming. Because the track needs to come back in at a much lower level, I have included a follow-on fade from the 'Pause' cue in readiness for the 'Play' cue.

 

However, when I go on the 'Play' cue, to resume, the audio come back in at a lower level, but with a horrible pop at the start. As if I have just put the jack into the machin mid-track.

 

Has anybody come across this issue with Qlab, or any other form of playback?

[neilalexrose]

However, when I go on the 'Play' cue, to resume, the audio come back in at a lower level, but with a horrible pop at the start. As if I have just put the jack into the machin mid-track.

 

I suspect that that horrible pop is the audio that comes through before the fade cue starts after the play command - the program catching up with itself 1/2 a second later!. Try putting the fade before the play cue, set to fire after the pause cue has completed. I can't try it right now as I'm in in dress, but I'm hoping the theory is right.

 

You get the same thing sometimes on digital desks, when they change desk scenes - all the channels un muting and re-muting in a split second, as the snapshot changes.

 

Neil

[Andrew Edwards]

I'm sorry Neil but I am having trouble working out what you actually mean.

The OP has stated that the fade cue is before the play cue not after. You solution appears to describe what the OP is doing already.

 

My first thought is that it could be because the the cue is restarting with the waveform at a non-zero level. The play/pause is tantamount to adding an on the fly edit. However, I cannot seem to recreate this on my Mac Pro and would have thought that Figure53 would have ensured that the pause cue actually stopped at the next zero crossing rather than straight away. After all, we are only taking a few samples.

 

My cure would be something I do anyway as I'm not a big fan of audio snaps. I would soften the pauses even if they are intended to be 'instant'. You can tailor the time to suit.

 

Assuming that the audio is required to be paused manually at an indeterminate point. Obviously you 'lose' 0.6s in this instance, I doubt anyone will notice.

 

• Fade cue down to infinity over 0.3s - auto follow
  
• Pause cue
  
• Play cue - auto continue
  
• fade cue up to the desired level over 0.3s
  

 

I'd be interested to know if the pops occur every time in any place on the audio, and/or with different audio files.

 

Andrew.

[jonnybrandon]

Thanks, RootTwo, that solved the issue. Not ideal but a good work around, just in time for press night.

 

Have only got one cue like this, so don't know if it would happen on other tracks.

 

Thanks again for your clear solution!

[TomHoward]

I have found that the Stop cues, and adjusting the start point into the track indiscriminately (which is essentially the same as using the Pause cue & resuming) does in many cases cause a pop because of the non-zero crossing. I've always gone with the solution about - a 100ms fade to silence with 'Stop Target When Done' instead of a stop cue, and if starting at a non-zero crossing start the track at silence and fade up over 100ms or so. I'd fade to zero, with a lead into a pause, and then play with an immediate fade up to -12 or whatever the adjustment is.

 

(Just for the record we're still using V1)

[neilalexrose]

My apologies, I read that the fade cue was coming after the second play cue, not before. In my mind, that was how the unpleasant noise would have happened.

If that hadn't worked, one other solution would be to run two instances of the same audio file at once (to keep them in sync), the second at the desired lower level. The pause cue would stop the loud audio, and pause the lower level file, the play would only start the lower level audio file. If it's a cue that's never going to happen in the same place, then its a work around, as opposed to a cue that stopped and started in the same place (where you could start a second audio file at the required point everytime.)

Possibly overcomplicating things though.

 

Neil