Network cues internally @ localhost stopped working.

[Johan]

I noticed in a template I made that when I disabled remote network access  to editing without password I also lost the function to run internal OSC-commands to my Qlab file.

I find it odd that the settings for external remotecontrol also affects the internal commands sent in the localhost by triggering a GO-button locally on the computer within which all commands are to be both sent and received.

My OSC-commands started working again when I allowed an account with no password also to edit cues. Previously I had that set to viewingrights only.

At opening of the file I wasn't prompted to choose if I was to use the account with or without password so I guess it opened without password, but then why did it allow me to edit ?

Must I really allow external remote users editing to get the OSC commands to work properly?

[Paul]

No. If in the Override controls External input is OFF you can still run Network cues internally to control and Edit QLab. Indeed it seems that "external" in this context is anything from another IP address; you still seem to be able trigger QLab via OSC from the same machine (which is slightly odd but I guess QLab has no way of knowing what is "local" apart from IP address). Removing the 'no passcode' Control permission results in the expected behaviour. And setting local input to OFF means QLab network cues to itself won't work. 

Here is a screen shot showing external network input OFF but a Terminal command still able to send /go to QLab to run cue 3.

In the OSC Access tab Edit permission is unchecked for 'no passcode'. 

 The passcode for OSC is not particular secure so you want to make sure your network is secure. It has quite a long time out period.

[Sam Kusnetz]

I think actually you two are talking about slightly different things.

 

The answer to the Johan’s question is: if you turn off “Allow OSC connections” that will

block all OSC messages coming into the workspace, even messages that originate from within the workspace. Unchecking that box will prevent any OSC messages whatsoever from controlling the workspace.

 

Johan’s follow up question was, I think, “how can I allow a QLab workspace to control itself with OSC, but prevent OSC from other sources?” And Paul’s exploration contains one way to do that.

 

QLab’s override controls let you override (block) OSC messages coming from external sources (other computers) or from local sources (the same computer QLab is running on) separately. So one way to allow only QLab to control itself is to leave the “Allow OSC connections” box checked, override external OSC access, and do not override local OSC access.

 

Another way to do it is to only allow OSC access with a passcode, and then don’t tell anyone the passcode!

 

Best

Sam

––
Sam Kusnetz [he/him/his] (what is this?)
Figure 53
https://qlab.app | https://figure53.com

On Apr 21, 2026 at 3:50 PM -0400, Paul <paulthom...@gmail.com>, wrote:

No. If in the Override controls External input is OFF you can still run Network cues internally to control and Edit QLab. Indeed it seems that "external" in this context is anything from another IP address; you still seem to be able trigger QLab via OSC from the same machine (which is slightly odd but I guess QLab has no way of knowing what is "local" apart from IP address). Removing the 'no passcode' Control permission results in the expected behaviour. And setting local input to OFF means QLab network cues to itself won't work. 

Here is a screen shot showing external network input OFF but a Terminal command still able to send /go to QLab to run cue 3.

In the OSC Access tab Edit permission is unchecked for 'no passcode'. 

<Screenshot 2026-04-21 at 20.40.06.png> The passcode for OSC is not particular secure so you want to make sure your network is secure. It has quite a long time out period.

On Tuesday, 21 April 2026 at 19:33:52 UTC+1 Johan wrote:

I noticed in a template I made that when I disabled remote network access  to editing without password I also lost the function to run internal OSC-commands to my Qlab file.

I find it odd that the settings for external remotecontrol also affects the internal commands sent in the localhost by triggering a GO-button locally on the computer within which all commands are to be both sent and received.

My OSC-commands started working again when I allowed an account with no password also to edit cues. Previously I had that set to viewingrights only.

At opening of the file I wasn't prompted to choose if I was to use the account with or without password so I guess it opened without password, but then why did it allow me to edit ?

Must I really allow external remote users editing to get the OSC commands to work properly?

--
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 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/d8ddee30-61bf-4200-aee8-c10099bd5431n%40googlegroups.com.

[Philip Perkins]

I tried using Baby Audio’s “Smooth Operator” plugin (VST and AU) in v5, having had great success with it in v4.   When a file using this plugin is fired in v5 there is a short delay, a 1-sec burst of the start of the track (not sounding like it is running thru the plug in), and then the full track plays.  This behavior was very consistent on 2 laptops with opdated OS and the latest QLAB version.

Is this fixable?  We’ve already lost the ability to use a number of plugins we like to use in v5, due to the app hesitating before each play of a file using that plug (not an issue in v4).  This issue are slowing us down, in that we have to use the plug in another app, render the file and then move that file to QLAB, instead of being to experiment with that plug within QLAB directly.  It was explained to me earlier that this was a function of some changes in v5, is it possible that a newer version will return the ability to use those plugs to us?

thanks

Philip Perkins

Sound Designer and Music Supervisor

Alonzo King LINES Ballet

26 Seventh Street, San Francisco, CA 94103

Cel: 510-734-2496

To view this discussion visit https://groups.google.com/d/msgid/qlab/896277d6-6720-4b79-a137-ded3becb3bf3%40Spark.

[Sam Kusnetz]

HI Philip

I think you should write to sup...@figure53.com about this. I have not noticed worse AudioUnit performance in QLab 5 and we haven’t heard about it in general, so I think it’s possible you’re encountering a problem which can be solved, or at least one which has more to discover.

No version of QLab has supported VST plugins, so that seems like a separate topic to me.

Best

Sam

—

Sam Kusnetz (he/him) | Figure 53

s...@figure53.com