QLab 5 Camera Cue Microphone permission

[Matt Weber]

Hi, I'm running Qlab 5 (5.0.6) and noticed the orange dot.  I know there have been a number of posts about this but this is a different question.  When I add a camera cue it is broken and the message states that it needs microphone access to work.  However, no input patch references a microphone.  I'm using a usb hdmi capture device and it is the selected video and audio input.  With qlab having microphone permission it displays the orange dot on the projection screen.  

It seems a bit strange, maybe a bug, that qlab requires microphone permission when no patch is using the microphone.  Am I missing something in terms of input settings?

Thanks,

Matt

[Sam Kusnetz]

Hi Matt

It’s possible that this is a side effect of the design of your capture card, and it just needs microphone access to work. It’s also possible that this is a side-effect of the fact that Camera cues in QLab 5 have the ability to work with live audio, a frequently-requested feature.

If you use the same video capture device with QLab 4, do you see the orange dot?

While I applaud Apple’s commitment to security overall, I find this particular set of security features very irritating.

Best

Sam

—

Sam Kusnetz (he/him) | Figure 53

s...@figure53.com

[Matt Weber]

I just tried the same video input with v4.  It worked without qlab 4 having microphone permissions or displaying the orange dot.  I actually do not want audio from this input at this time.  It is a preshow ad projection.  At this point it looks like v5 camera cue always requires internal microphone permissions.  It explicitly asks for that permission in the error message.

Matt

[Chris Ashworth]

Thanks Matt, appreciate this report — I’ve filed this to look at for the next update

-C

[Matt Weber]

Great, hopefully you can work it so that the camera can access audio input without the microphone permission.

One other item I stumbled accross while testing this.  It does not appear that the camera cue honors audition.  I turn on always audition and all my video cues look good and play in the audition window.   The camera cue still says select a valid video output stage even though it uses the same stage as the video cues and qlab is in audition mode with the audition output for video set to redirect to audition window.

For now, since I do not need the audio from the camera cue, I found that if I make the audio unpatched the camera cue works without the microphone permission and avoids that awful orange dot.  This is much better than my other options of rebuilding in v4 or running v4 for the camera cue then switching to v5.

Thanks,

Matt 

[Chris Ashworth]

Hi Matt,

I’m not able to recreate your issue with camera cues and auditioning; they honor the audition setting when I use it.

If you’d like for us to dig in please write to sup...@figure53.com with details and steps to reproduce, thanks.

-C

[Matt Weber]

To my embarassment, niether was I this morning when I was prepping for this weekend's events.  I did see something yesterday so I will watch and if I figure out a pattern I'll email support.

One item which may be of interest. I'm sure you know but it looks like the camera audio and mic cue are sharing the same underlying code.  Once I found that I could run the camera cue with no audio input patch I wondered if I could build a work around by using a mic cue with the same audio input.  The mic cue also required microphone permissions when using a line input.  I tried replicating this in v4 and did not see the mic permission requirement on th v4 mic cue.  

This was just me trying to make it work even though I don't need camera audio now.  I'm a software engineer by day so I like to figure these things out :-)

Matt

[Seablade -]

> One item which may be of interest. I'm sure you know but it looks like the camera audio and mic cue are sharing the same underlying code.  Once I found that I could run the camera cue with no audio input patch I wondered if I could build a work around by using a mic cue with the same audio input.  The mic cue also required microphone permissions when using a line input.  I tried replicating this in v4 and did not see the mic permission requirement on th v4 mic cue. 

I could be wrong, but microphone permissions is more generally just any audio input permissions based on my knowledge of this.  Given this I am wondering, is it possible you already granted microphone permissions to QLab v4?

    Thomas Vecchione

--
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/8451da04-bca8-4484-9d82-f2a14f756187n%40googlegroups.com.

[Matt Weber]

I checked before launching.  Microphone permission was not granted for qlab v4 or v5.   

[Chris Ashworth]

v4 Camera cues did not support audio, so they did not require microphone permissions. 

v4 Mic cues require the same permissions as both v5 Mic cues and v5 Camera cues with audio; the permission needed is for any audio input. 

[Chris Ashworth]

Hi all,

We’ve made an adjustment for 5.0.7 so that QLab should more pro-actively turn of audio inputs if no patch or cue needs them.

We’ve made a beta build with this and other recent fixes available here:

https://figure53.com/temp/QLab-5.0.7-b3.zip

And would be grateful to learn if this works as expected for you.

Best,

Chris

On October 10, 2022 at 10:22:44 AM, Chris Ashworth (ch...@figure53.com) wrote:

Thanks Matt, appreciate this report — I’ve filed this to look at for the next update

-C

On October 10, 2022 at 10:19:31 AM, Matt Weber (mattg...@gmail.com) wrote:

I just tried the same video input with v4.  It worked without qlab 4 having microphone permissions or displaying the orange dot.  I actually do not want audio from this input at this time.  It is a preshow ad projection.  At this point it looks like v5 camera cue always requires internal microphone permissions.  It explicitly asks for that permission in the error message.

Matt

On Monday, October 10, 2022 at 9:55:18 AM UTC-4 sam kusnetz wrote:

Hi Matt

It’s possible that this is a side effect of the design of your capture card, and it just needs microphone access to work. It’s also possible that this is a side-effect of the fact that Camera cues in QLab 5 have the ability to work with live audio, a frequently-requested feature.

If you use the same video capture device with QLab 4, do you see the orange dot?

While I applaud Apple’s commitment to security overall, I find this particular set of security features very irritating.

Best

Sam

[Matt Weber]

I checked the beta and I do not see a change in behavior wrt the need for the mic permission.  The camera cue (and mic cue) still require mic permssion for any input patch.  If this is an OS restriction where the mic permission is required for ANY input not just the internal microphone then Apple has definitely cast the net too wide for this permssion.  

When faced with an over agressive permission structure and an annoying display artifact it really starts to feel like there needs to be a more "pro" version of MacOs without some of the restrictions.  Maybe a MacOs "Home" and "Pro" ;-)   

For completeness to compare with V4 I created an aggregate device with the internal microphone and builtin output as the components.  I found that as I reported before the cue did not appear as broken but it failed to work without the mic permission for any input.  The V4 mic cue also only worked with a loopback device (soundflower) with the mic permission.  In this regard the V5 behavior is better because it does not fail silently when lacking the permission.  I originally thought all was well with this in v4 when there was no broken cue indicator without actually running a test.

Thanks,

Matt 

[Sam Kusnetz]

Hi Matt

To be clear: the change we made doesn’t stop macOS from asking permission when you first set up a Camera cue.

All it does is make it so that after the Camera cue exists, if you unpatch its audio input connection in the I/O tab, QLab will release the input device and therefore turn off the orange demon dot.

You can also configure the Camera cue template to use no audio input patch, so that you don’t have to manually unpatch it every time you make a new cue.

Can you confirm, please, whether unpatching the audio input does indeed switch off the dot?

Thanks

[Matt Weber]

I just ran some tests and can confirm the orange dot does go off when the patch is removed from the camera cue or the mic cue.  The mic cue as expected does get the red x because of no patch at that point.  I added and removed the patch several times and saw the dot go on and off with the patch assignment.  I then deleted the mic cue while it had an assignment and the camera cue had none.  The dot did not go off but reopening the work space made it go off.  I repeated this two more times and on these attempts the dot did go out as I deleted the mic cue.  Not sure what happened the first time but solving it was as easy as reopening the workspace.

Long term solutions:  I did set up an NDI monitor on an another system using the NDI tools studio monitor.  The orange dot is not added to the NDI feed so MacOS must only do this to physically attached displays.  I could see investing in an NDI to HDMI bridge or an NDI projector if I frequently needed to input audio and project.   However, that probably won't happen anytime soon because the projector at my theater still only has DVI input, its too old for HDMI but it still works well.

Matt

[Seablade -]

Just to be clear, the Orange Dot is a security 'feature' in MacOS.  It comes on any time an audio input is used (Mic or Line).  And yes it seems to only be rendered on displays connected to a video card in the computer (So NDI and native SDI outputs would not see it, but a converted HDMI out from the computer to SDI would, as would any native HDMI output from the computer).

Similarly the request to use a microphone is actually a security requirement as well, and applies to ANY audio input.  Again this is at the operating system level and is required in order for QLab or any software to utilize any audio input device.

    Thomas Vecchione

--

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/ae236002-12e5-4608-b2f2-094f537e3fe4n%40googlegroups.com.

[Seablade -]

On Thu, Oct 13, 2022 at 8:22 AM Matt Weber <mattg...@gmail.com> wrote:

Long term solutions:  I did set up an NDI monitor on an another system using the NDI tools studio monitor.  The orange dot is not added to the NDI feed so MacOS must only do this to physically attached displays.  I could see investing in an NDI to HDMI bridge or an NDI projector if I frequently needed to input audio and project.   However, that probably won't happen anytime soon because the projector at my theater still only has DVI input, its too old for HDMI but it still works well.

Also for the record, assuming the input is compatible with DVI-D HDMI to DVI-D is a simple passive cable so you could easily get a NDI to HDMI converter, and then a HDMI to DVI-D cable to connect that to your projector.

     Thomas Vecchione

[Sam Kusnetz]

I hate the orange dot as much as everyone else, but I feel compelled to say that it came into being to address a very real security risk: before the orange dot, there was no way for the person using the Mac to be aware that a program was listening to the mic. This is, without question, a serious problem and I’m glad it’s being addressed by Apple. I would prefer for it to be addressed in a way that does not interfere with video output, of course, and I look forward to an eventual solution.

Best

[Matt Weber]

I won't disagree with the need but I have issues with the implementation of the solution.  First, the dot could be placed in the top bar along with all the other information where a user might view other information about the system.  Why is it the only thing plastered onto the secondary (full screen) display?  Second, I would have no problem if the microphone permission addressed THE MICROPHONE, not every input device.  At least rename the permission to match what its for. <sarcasm>  I had this strange idea that the permission was for the microphone...can't imagine why </sarcasm>  

I have a way to do what I need so I'm good, just taking a run at the Apple windmill.

Matt