Audio stutters during level change while playing

[Justin]

Hi all!

I'm trying to come up with a way to manually adjust active audio cue levels while they're playing, but it seems that any time you change a level slider in the "Audio Levels" tab of the inspection, the audio that's playing will intermittently stutter a bit. This happens with ganged channels as well as individual as well as changing levels with an OSC fader e.g. "/cue/active/level/0/1 x"

Happens every time with a .wav or .mp3.

2 different machines-

MacBook Pro 13" 2018, 16GB, SSD, 11.6.1

MacBook Pro 13" 2015, 16GB, SSD 10.15.7

Any suggestions?

Thanks!

[micpool]

This somewhat depends on what you mean by stutter....

If you mean that when playing something like a 1KHz tone you can hear zipper noise when moving the sliders, I would agree. QLab isn't completely  optimised for live manipulation of slider levels, and the smoothing algorithm used on the sliders doesn't always produce results comparable to moving faders in a DAW. Although, when levels are changed through a fade cue, which is more likely to be the case when an audience is present, the results are usually superbly  smooth. 

However, on actual  music or speech program material, moving a  slider in a  reasonably controlled fashion   or sending a series of OSC messages, without swamping the system, doesn't usually result in much audible zipper noise.

Any zipper noise or similar artefacts are  slightly more audible when running an interface at 96Khz or more, and roughly  proportional to the number of ganged faders.

In  neither case would I describe what I hear as a stutter. If you are actually getting repeated samples then probably something beyond the norm is happening on your systems.

I have to say I, and many other users,  have adjusted literally  millions of cues while they are playing, and whilst the sliders may not be the most  refined controls for  level adjustment when compared to a ProTools, or a hardware  mixer fader , I have rarely been concerned or given a second thought  to artefact audibility. It just hasn't been an issue.

Can you record a few seconds of the sort of stuttering you are referring to  and post?

Mic

[Justin]

Hi Mic,

Thanks for your response! I guess stutter might not be the best descriptor, but neither is zipper for me... maybe hiccup? I dunno. I'm attaching a recording of what I'm talking about. The first fade out is moving the master volume slider. The second is moving output slider 1, with 1 & 2 ganged together.

This is from a brand new install of macOS Big Sur on a MacBook Pro Retina 13-inch Early 2015, with nothing installed except QLab and Audio Hijack. I ran this beforehand. The only thing in the workspace this is recorded from is a 10 min tone .wav file dropped in as an audio cue.

This happens almost every time I move any slider with any audio. Much less with an mp3 though. It's pretty random, sometimes it's pretty bad, sometimes it's barely there. But however you slice it, it's unusable for broadcast.

At this point I've found a workaround using Loopback to insert Element before my output device, and their built-in faders controlled with MIDI. One of the QLab folks also pointed me at LevelBox which is pretty nifty and should do the trick as well.

Let me know if you have any other thoughts!

Cheers-

Justin

[Chris Ashworth]

Hi Justin,

Thanks for the questions & detailed description!

The answer is: In general, QLab is not designed such that edits in the inspector are expected to be possible during a performance.

Edits to various audio related properties, including the volume levels, are not currently designed to support glitchless playback while the edits are being made. In this case, changing the initial volume levels of a cue causes it to reset the levels for the cue, which includes a brief “reset everything to silence” step as it reconstructs the starting values. So these stutters are the brief moments as that rebuild is happening.

This is something we could consider working on changing, but at the moment this is indeed the expected behavior.  I believe that at the moment the only mechanism to change the volume which would be guaranteed to avoid this is running a Fade cue to adjust the volume.

Best,

C

[Justin]

Hi Chris-

Thanks for the explanation! Is there any plan to add any sort of “on the fly” volume adjustment mechanism?

Cheers-

Justin

[micpool]

As people have said, the only way to absolutely guarantee a smooth and glitch free audio level change is using a fade cue, or using something like LevelBox in a cue output effects slot.

To be able to suggest the best solution for your broadcast use case I’d need to know a bit more about when fade cues wouldn’t work for you, and you would need to use manual adjustments. Also would these just be small level adjustments, or would you be wanting to do a full fade in or out manually? How would you want to select the cue you wanted to adjust the level for, and what would be your favoured physical control e.g + or - hotkeys, hardware fader, onscreen fader etc.

[Philip Perkins]

Has anyone heard from Widgeteering Studios lately?
I bought one of their “Show Control Remote” units to run two
QLAB macs at the same time. They took my order and $ back in
October and haven’t responded since, and no remote has arrived.
Has anyone gotten a delivery or a communication from them in the
last few months?

thanks

phil p

[jimsta...@zoho.com]

That would be in another thread, doesn't sound good.

https://groups.google.com/g/qlab/c/JUPaHAu9uhs

Jim

[micpool]

I've just been giving some thought to how fades could be used to change the audio level of a selected cue,  'on the fly' to another arbitrary level.

Thinking about what happens when we use an analogue fader to adjust a level.

As we move our hand towards the fader we decide whether we are going to increase the level or decrease it, and how fast we are going to move the fader. i.e if the current levelis much too loud we are going to move the fader down very quickly. If the current level is fractionally quiet we are going to creep the fader up slowly.

When we action that decision we are listening to the audio to decide when it is at the correct level, and when it is we stop moving the fader.

Hopefully that model will be recognised by most people as roughly the thought process that goes into a level adjustment.

So to map that process onto a cue structure we need to be able to change the target of a fade cue, with an appropriate duration for the desired speed, to the selected cue, and then start that fade. When the audio is at the correct level we need to stop the fade wherever it is to park at the correct level.

We could create 6 RELATIVE fade cues. 3 would increase the level (build) to a relative level of +59.5dB  at 3 different speeds Slow/Medium/Fast  6dB per sec/ 12dB  per second/ 30dB per second  i.e durations  of 10s/5s/1s and 3 would decrease the level by -59.5 dB.

The triggers for these fades could be arranged on the numeric key pad 1-3 for slow to fast fades 4-6 for slow to fast builds.  (You could also use a MIDI keyboard for these triggers)

A second trigger,  with on key release checked, would  be set to hard stop the fade 

The only remaining thing would be to set the targets for these fade cues to the currently selected cue on the fly.

We could do this by creating a timeline group with one of the  fade cues and putting a network cue with an OSC message as the first child of the timeline group. We would put the triggers on the timeline group instead of the fade cues with the same settings.

The OSC message to set the target of a  Slow Fade numbered "SF" to the selected cue  might be

 /cue/SF/cueTargetNumber "#/cue/selected/number#"

(At the moment I think any target cues have to be numbered, I can't find a way of getting the cue_ids with an OSC query)

As a starting point this seems to work very well, and gives perfectly smooth  sounding fades with a good degree of  control.

Example  Screen recording attached. Workspace in next post

[micpool]

Workspace for previous post

[micpool]

Real world example screen recording

[Philip Perkins]

and now it is!

https://groups.google.com/g/qlab/c/0cGf-CfPR-0

--
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/9ebc62d9-b218-42eb-b390-0a8c25b230f3n%40googlegroups.com.

[micpool]

On Saturday, January 8, 2022 at 10:34:30 PM UTC micpool wrote:

The OSC message to set the target of a  Slow Fade numbered "SF" to the selected cue  might be

 /cue/SF/cueTargetNumber "#/cue/selected/number#"

(At the moment I think any target cues have to be numbered, I can't find a way of getting the cue_ids with an OSC query)

This was of course a complete brain freeze! If you use this it will work regardless of if a cue is numbered.

/cue/B1/cueTargetId "#/cue/selected/uniqueID#"

It also occurred to me that a Contour Shuttle  would be an ideal controller for this.

I expanded the fade groups  to 7 speeds in each direction, set keyboard triggers and mapped these to the 14 zones of the shuttle wheel like this

For use in this workspace attached:

 

Workspace attached with Contour ShuttleSettings for import.

The audio control is absolutely  smooth and glitchless, and the seven fade speeds on the shuttle wheel give very fine control over the live level adjustment.

I think this is the only way to provide any sort of audio level adjustment to cues without altering the slider settings (equivalent to OSC /liveLevel if it existed).

Conversely, I have not found a way to do this as the equivalent of /level i.e altering the actual slider settings for potential saves with the same guarantee of completely glitch free level changes.

I'm not sure I would need a method to control the live levels of selected cues without changing the slider levels that often, I am more likely just to use something like LevelBox in a cue output effects slot and control that with OSC for temporary master levels, but if you need to do  this on a selected cue basis  is possibly the best (only)  method.

Mic

[jimsta...@zoho.com]

Mic once again the wizard. Waves a magic wand, a device appears and he programs it while everyone else is watching the telly.

However I can't see replacing an actual desk - with instant hands on - for many of the manual fade issues users have presented.

From my experience, in the heat of battle you barely think about the dynamics of a fader move, it just happens. *

Jim

* With band member's wives and the manager all standing next to you might be different.

[Joe Wilson]

I am sorry to voice this opinion, but I think at this point it is appropriate to consider them out of business and file a fraud report with your credit card company in the hopes that they can recover something.

~joe

--

_________________________
Joe Wilson, ATD/Sound
Indian River State College

Adding one more "me too" to the
collective internet consciousness.

[Philip Perkins]

thanks.  From what I’ve heard from others and in light of no communication from Widgeteer I am inclined to agree…..

phil p

--
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/CALPCkUoApwyyz2UfXHzyopk6uk%2BqOqAEBhpRVTu8TeB_X%3D9oeQ%40mail.gmail.com.

CONFIDENTIAL COMMUNICATION: This email message and any attachment may contain privileged and confidential information intended only for the use of the individual or entity to which the email is addressed. If the reader of this message is not the intended recipient or the employee or agent responsible to deliver it to the intended recipient, that person is hereby notified that any dissemination, distribution or copying of this communication is prohibited. If you have received this communication in error, please notify us as soon as possible by emailing the intended recipient. Thank you for your cooperation and assistance.

[micpool]

On Saturday, January 8, 2022 at 12:16:20 AM UTC Justin wrote:

Thanks for your response! I guess stutter might not be the best descriptor, but neither is zipper for me... maybe hiccup? I dunno. I'm attaching a recording of what I'm talking about. The first fade out is moving the master volume slider. The second is moving output slider 1, with 1 & 2 ganged together.

This happens almost every time I move any slider with any audio. Much less with an mp3 though. It's pretty random, sometimes it's pretty bad, sometimes it's barely there. But however you slice it, it's unusable for broadcast.

If you do want to change the main  slider settings  to effect a level change on a playing cue , with the potential for saving the change, while (almost) guaranteeing  that there will be no glitching or audio artefacts, and inaudible steps between level changes  , I think the only way of doing this is with  network cues with  the following OSC messages.

/cue/selected/level/0/0/- 1

/cue/selected/level/0/0/+ 1

with hotkey triggers, e.g 1 for minus 2 for plus

For rehearsal use you can also have larger delta values, although the steps will be increasingly audible. In my standard hotkey map I have 1dB 2dB and 3dB hotkeys  plus and minus, which covers most main slider  level changes I need to make on the fly during rehearsals (and sometimes during performances)

If only a 1dB step was acceptable (similar to the resolution you would get if you control a fader in a different app with a MIDI cc controller), this would obviously require you to press a key up to 60 times to fade 60dB  in either direction. Fine for small level adjustments, but too slow  to effect a large change in a timely manner.

It would be possible to resend the OSC message at a predetermined rate, and use second triggers "on key up' to stop the resending. At resend frame rates up to 5fps (QLab's maximum for identical messages, see below) there is a good chance you won't get any audible glitching, (although transitioning from + to - deltas quickly  sometimes produces a glitch) but any higher fps  has a higher chance of glitching, and  very high fps rates may actually crash the workspace. 

Because level change OSC messages with a delta are identical, QLab filters repeated messages to give an effective maximum resend rate of  of 5fps. If you want to experiment with higher fps then you have to append a dummy non identical value to your level change address. The best way to do this is to use a 1D fade to produce the appended values like this:

But I would really caution against this, as high OSC resend rates can make QLab miss 'Key up' second triggers, or the sheer volume of OSC messages may cause a spinning beachball for a few seconds or a crash!

This is however a very useful technique for using high OSC resend frame rates for non audio cue properties e.g to move  the x coordinate of a video cue relatively by OSC  e.g 

/cue/selected/translationX/0/0/- 1 #v#. 

You can resend 120 of these OSC messages a second and Qlab will update the x parameter in the geometry tab in real time, and smoothly animate the x coordinate of the video cue, and will do this all day long. Same with OSC sent to the lighting dashboard for leve and parameter l changes to lights

Doing this with audio cue  levels  is not nearly as successful or reliable. The level slider will only update occasionally,  the audio itself may  glitch, and the repeated OSC messages will quickly overwhelm the audio sliders ability to deal with them. 

Mic