Applescript Crashes QLab

[nizer]

I have been struggling with this issue for a long time and have narrowed it down to AppleScript Cues that include the < say "whatever you want apple voice to say">

I use this a lot to help during set up and to include variables in live voice overs.

They mostly work fine, but after I use several in a rows,  I sometimes (not always) get the QLab is not responding rainbow wheel of doom. I am force to force quit and reopen. 

I have tried run in separate process on or off with no joy.

Just something to check on. 

In the mean time I have removed all the cues that include this and converted them to recorded audio cues which means no more live variables. :-(

[Drew]

Hey Nizer,  

I have been testing this and I cannot get SWoD (spinning wheel of death).  The way I have done it though may be different to how you have done it.

I made scripts with various say command and then called them via applescript.

If you aren't familiar with shell scripts this is what i did:

in my home path ie: ~/ 

vim say1 to open a text editor and call the file say1

hit i to enter insert mode

#!/bin/zsh 

say whatever you want the computer to say

hit esc then :wq to save and quit

chmod +x say1 to make the say1 file into an executable

then in qlab add this script

tell application "Terminal"
if (count of windows) is 0 then
do script "~/say1"
else
do script "~/say1" in window 1
end if
end tell

I haven't been able to get qlab to crash using this method and I am trialing this for you on a 13" 2017 macbook pro running ventura 13.7.8

Drew

[Mark Nizer/Neisser]

I love that you’re interested in this issue. It is just the most simple AppleScript in the world simply the 

say “say whatever here“

I used this for years to help identify issues in the show and give feedback about things I was doing with no issues at all. But in the last couple years, it is consistently crashed Qlab. I no longer use any of these in my show. I simply record the audio and have it be an audio file. The bummer is it takes out the wild card part which could give me a real time feedback on things that we’re going wrong

Mark Nizer/Neisser

📩 Ni...@active-media.com

📲 434-974-9699

💻 http://activemedia.org

💻 http://Nizer.com

On Aug 20, 2026, at 2:19 PM, Drew <stcsa....@gmail.com> wrote:



--
Contact support anytime: sup...@figure53.com
User Group Code of Conduct: https://qlab.app/code-of-conduct/
 
Instagram: https://www.instagram.com/Figure53
TikTok: https://www.tiktok.com/@QLab.app
Bluesky: https://bsky.app/profile/qlab.app
---
You received this message because you are subscribed to a topic in the Google Groups "QLab" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/qlab/Th_hO0mP-0Y/unsubscribe.
To unsubscribe from this group and all its topics, send an email to qlab+uns...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/qlab/ec7e397e-751b-4c70-9cc0-f8982bfd4a8an%40googlegroups.com.

[Drew]

I tried it that way and just putting a say command in an applescript in qlab is incredibly slow.  if you want to do this again rather than using recorded audio then I would use zsh shell script.  I found just using applescript in qlab to issue a say command just to say "hello" was around 6 seconds which is an amazingly huge amount slower than using shell script.  which is more in the low milliseconds mark.

if you want to use shell script though make sure you include the shebang for your shell.  

ie: #!/bin/zsh

Drew

[micpool]

If you use a say command in AppleScript with 'run in separate' process unchecked then the QLab interface will do nothing until the speech has finished (although on my system the ESC key works). If the length of the speech exceeds the timeout (around 2 seconds) which results in the beachball being triggered, that will appear on screen. If you have multiple consecutive short say commands the interface will do nothing, but the beachball won't appear as each consecutive command will reset the beachball timeout.

I can't replicate the 6 second delay in speaking on my system (M1 Sonoma). A Say command run in seperate process causes around 0.3s longer delay to a say command, compared to running with  the checkbox being unchecked, regardless of the length of text in the say command.

[micpool]

Actually I can replicate the 6 sec delay that Drew reports, but only the first time I run a script with a say  command when QLab is opened immediately after a mac restart (presumably because other processes are running which interfere) the next time I run it there is no long delay. The delay is exactly 6 seconds as Drew recorded, so it may be that there are some background processes that will delay the say command, which might occur in different circumstances as well as the restart scenario I describe.

[Mark Nizer]

I guess this is the source of the crashing. I had many scripts with “SAY” using it as a real time set up engine and show time interactive voice. But the consistent  crashing has forced me out of that.

What do you think of the shell script idea.

In QLab Applescript Cue: 

set WhatToSay to "hello this is a test"

do shell script "/usr/bin/say " & quoted form of WhatToSay

Active Media Group

State of the Art Internet and Multimedia

Mark Neisser

ni...@active-media.com

On Aug 21, 2026, at 3:36 AM, micpool <m...@micpool.com> wrote:

Actually I can replicate the 6 sec delay that Drew reports, but only the first time I run a script with a say  command when QLab is opened immediately after a mac restart (presumably because other processes are running which interfere) the next time I run it there is no long delay. The delay is exactly 6 seconds as Drew recorded, so it may be that there are some background processes that will delay the say command, which might occur in different circumstances as well as the restart scenario I describe.

On Friday, August 21, 2026 at 12:19:05 PM UTC+1 micpool wrote:

If you use a say command in AppleScript with 'run in separate' process unchecked then the QLab interface will do nothing until the speech has finished (although on my system the ESC key works). If the length of the speech exceeds the timeout (around 2 seconds) which results in the beachball being triggered, that will appear on screen. If you have multiple consecutive short saycommands the interface will do nothing, but the beachball won't appear as each consecutive command will reset the beachball timeout.

I can't replicate the 6 second delay in speaking on my system (M1 Sonoma). A Say command run in seperate process causes around 0.3s longer delay to a say command, compared to running with  the checkbox being unchecked, regardless of the length of text in the say command.

On Wednesday, July 1, 2026 at 4:23:01 PM UTC+1 nizer wrote:

I have been struggling with this issue for a long time and have narrowed it down to AppleScript Cues that include the < say "whatever you want apple voice to say">

I use this a lot to help during set up and to include variables in live voice overs.

They mostly work fine, but after I use several in a rows,  I sometimes (not always) get the QLab is not responding rainbow wheel of doom. I am force to force quit and reopen. 

I have tried run in separate process on or off with no joy.

Just something to check on. 

In the mean time I have removed all the cues that include this and converted them to recorded audio cues which means no more live variables. :-(

-- 
Contact support anytime: sup...@figure53.com
User Group Code of Conduct: https://qlab.app/code-of-conduct/
 
Instagram: https://www.instagram.com/Figure53
TikTok: https://www.tiktok.com/@QLab.app
Bluesky: https://bsky.app/profile/qlab.app
--- 
You received this message because you are subscribed to a topic in the Google Groups "QLab" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/qlab/Th_hO0mP-0Y/unsubscribe.
To unsubscribe from this group and all its topics, send an email to qlab+uns...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/qlab/f1bd6a97-8a5d-4c1c-a5b4-75e33ff663ccn%40googlegroups.com.

[Johan]

I second that weird 6 sec delay.

Noticed it first a few system updates ago. Nowadays I end my startscript-group with a "say-script" . 

That´s usually ridiculously late, but then all say-scripts after that have more acceptable delays..

No idea what caused this but me experience is that no matter what else is going on in the computer, the first run is always slower than the following.

[Rich Walsh]

Google could be hallucinating, but it seems moderately likely that the speech synthesis daemon is on-demand, meaning that it doesn’t load on restart – only when called. This would mean adding something to your login items to force it to load on restart.

Apparently AppleScript “say” and shell “say” are both calling the same speech engine anyway, but you can make the latter asynchronous by appending & and rerouting the data streams – as in do shell script "say '42' > /dev/null 2>&1 < /dev/null &".

Try this:

do shell script "say 'You’re not going to like it.' > /dev/null 2>&1 < /dev/null &"

beep

delay 3

do shell script "say '42' > /dev/null 2>&1 < /dev/null &"

Rich

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 visit https://groups.google.com/d/msgid/qlab/4b181ae3-af7b-4058-afb0-342f364c6989n%40googlegroups.com.

[Drew]

I didn't think or sending stderr and stdout to dev/null with that.  

[Mark Nizer/Neisser]

Can you explain that sentence a little bit better to me?

Mark Nizer/Neisser

📩 Ni...@active-media.com

📲 434-974-9699

💻 http://activemedia.org

💻 http://Nizer.com

On Aug 23, 2026, at 7:29 PM, Drew <stcsa....@gmail.com> wrote:



To view this discussion visit https://groups.google.com/d/msgid/qlab/dd3c5bb0-92a1-4ec6-b2ef-3b9f2452b8c1n%40googlegroups.com.

[Drew]

Hey Nizer,  /dev/null is like a digital blackhole on unix type systems like macos and all linux distros.  The 2>&1 that Rich has in the script is telling the computer to send standard error and standard output to that blackhole while maintaining the command you called.  It is used to squish error output and regular output from commands. 

Drew

[Drew]

Here is a much better but more technical explanation than mine: https://linuxvox.com/blog/what-does-dev-null-dev-null-at-the-end-of-a-command-do/

[Rich Walsh]

The important bit is appending "> /dev/null 2>&1 < /dev/null &” after the call to say, especially the & at the end.

• > /dev/null : discards standard output so AppleScript doesn’t sit waiting for it – "do shell script” is designed to wait for a response
• 2>&1 : discards error messages so AS doesn’t get thrown (or wait for them too)
• < /dev/null : disconnects standard input so the say command also isn’t waiting for anything (possibly optional)
• & : makes the command run in the background  – which, crucially, means the AS thread can continue no matter how long it takes for the speech daemon to respond

If you remove either the output redirects or the final & then AS sits there waiting for the speech daemon before moving to the next step. Testing again I’d say my daemon had gone to sleep since Saturday, despite not having restarted – so your first say after an undetermined time looks like it’s going to be unresponsive.

I thought making the speech run in the background might help with the apparent hanging?

Rich

To view this discussion visit https://groups.google.com/d/msgid/qlab/8a9382ed-545e-4ecf-95ce-a978f75eea77n%40googlegroups.com.

[Drew]

I could't get the hang when i wrote say commands to zsh scripts and called the scripts in qlab instead of calling via applescript in qlab.

Drew

[Mark Nizer]

Wonderful. I will totally revisit.

Active Media Group

State of the Art Internet and Multimedia

Mark Neisser

ni...@active-media.com

To view this discussion visit https://groups.google.com/d/msgid/qlab/57e7bc5e-ee37-4225-8542-19ee665d8e31n%40googlegroups.com.