Time code STOP

113 views
Skip to first unread message

Asa Wember

unread,
Jul 22, 2025, 12:31:43 PMJul 22
to QLab

Hello -


On my last job, I encountered an issue using timecode that derailed me pretty bad, and want to see what options I might have had.


I was running video for shows controlled by an audio QLab workspace on a second computer sending LTC — portions of the shows were time-coded, and other portions were not. 


Despite the "On Stop" setting set to "Do Nothing", the entire workspace ceased to function when the incoming clock stopped — on cues that were NOT set to timecode trigger, the post-waits would count down to 00:00 and then freeze, not firing their continues.  Prewaits and Start cues behaved the same way, counting out their internal timer but not executing their action.


I went through many restructures to try and fix this; shifting from post-wait continues to pre-wait start commands, and even moving content to a second cue-list which was not set to sync to incoming code.  Nothing was any use at all; as of the entire application was tied to that clock.


Eventually I had to render out all the component parts into a single movie that was started during the running clock, and simply played to completion.


This behavior seems at odds with QLab's inherent flexibility with regards to unusual use-cases.


Let me know how I could have handled this situation.


Thank you.



Chris Ashworth

unread,
Jul 23, 2025, 10:57:45 AMJul 23
to Asa Wember, ql...@googlegroups.com
Hi Asa,

Thanks for this report.

It’s a bit challenging to discuss without looking at the workspace, knowing what version of QLab you’re using, etc.

So what I’d like to suggest is to email us the workspace at sup...@figure53.com with a description of how to recreate the behavior you were seeing, and then we can have a more specific starting point to determine if there is a bug, a misunderstanding about intended behaviors, or something else.

best,
Chris

Andrew Nagy

unread,
Jul 25, 2025, 12:40:51 PMJul 25
to ql...@googlegroups.com, Asa Wember
Strangely I am also experiencing the same issue in nearly the same setup. I’ve started working with support on narrowing it down. 

Of course I’m in the middle of a live show so I’m trying to work around the issue right now. 

One of my thoughts is create another cue list. Have that cue list sync to time code and have that cue list send OSC to Qlab itself to trigger cues in the primary cue list. Make sure to unsync the primary cue list from timecode

I’m going to try my workaround later tonight while continuing to work with figure53 on a solution. 


Andrew Nagy


--
Contact support anytime: sup...@figure53.com
User Group Code of Conduct: https://qlab.app/code-of-conduct/
 
Instagram: https://www.instagram.com/Figure53
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/CADv1a48Bx6cjjJWqENTPhhVvNzMxAq8CqfADjm4-X0Y%2BZVfWXQ%40mail.gmail.com.

Chris Ashworth

unread,
Jul 28, 2025, 11:03:38 AMJul 28
to Andrew Nagy, ql...@googlegroups.com, Asa Wember
Following up on this, I dug in to it a little bit and wanted to share some of the technical background for what is happening.

The action of the cue is the thing that is (currently) either paused, stopped, or left alone when timecode stops.

In contrast, we're scheduling pre-waits and post-waits on the timeline which has stopped, and if that timeline stops, in a sense it is working “correctly" at the moment that the passage of time halts, and the action or auto-follow is not triggered.

Put another way: there are at least two clocks involved here:

- the clock running the timeline, which is also running the waits, and
- the clock running the media, which is either an audio or video clock (or both)

When the clock running the timeline stops, we have behavior specified for how it affects the media, but it does actually stop time for the waits.

This is one of a number of subtle considerations that come from allowing QLab to mix many different clocks together in one workspace, which is helpful in many ways but can also lead to unexpected results.

We have a number of thoughts on this for future work, which I won’t get in to now, but just wanted to share the above details in case people are curious about what is going on here.

Best,
Chris
Reply all
Reply to author
Forward
0 new messages