Timecode Triggered cues

[micpool]

I have seen  a few people getting confused about multiple cues being triggered from timecode. There is a very easy trap to fall into here.

Imagine you have 3 cues (or groups)  set to trigger on TC 1:00:00.00, 2:00:00.00, 3:00:00.00

If these cues (or cues contained in a triggered group ) have a duration of  greater than an hour, they will  be triggered by timecode from a  SUBSEQUENT  hour.

This also applies to audio cues with infinite loops, video cues with still images with no duration set, and hold at end videos (although there may be a bug here as the last frame of hold on end videos doesn't seem to display if the video triggered by TC should be on it's last frame)

Mic

[micpool]

Despite seeing hold on end videos running but displaying a black frame, when triggered by TC beyond the length of the video,  several times this afternoon, I can't replicate it again so can't send it as a support request or bug report. It was probably due to an unusual sequence of workspace edits as I was testing various Timecode options, so can be ignored.

Mic

[glp...@gmail.com]

Just trying out V5 after running on 4. We have a bit of infinite loop cues triggered with timecode. Is there an option to not use the chase feature and trigger cues via timecode the "V4" method where it just triggers instead of chases?

[micpool]

On Wednesday, January 18, 2023 at 11:32:50 PM UTC glp...@gmail.com wrote:

Just trying out V5 after running on 4. We have a bit of infinite loop cues triggered with timecode. Is there an option to not use the chase feature and trigger cues via timecode the "V4" method where it just triggers instead of chases?

No option, and I have so far failed to discover a work around.

Mic

 

[Richard Williamson]

Could you not use a start cue to fire the group - with the start triggered by timecode?

Sent from my iPhone

On 19 Jan 2023, at 01:54, micpool <m...@micpool.com> wrote:

--
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/4d890393-9abf-4bba-a6c1-e68eab5587d7n%40googlegroups.com.

[micpool]

That was my first thought when this was discussed  some time ago. It doesn’t work for the reasons in this thread

https://groups.google.com/g/qlab/c/jypvuFAFj5Q/m/s03efPwXBwAJ

[micpool]

My conclusions are in this post in that thread

https://groups.google.com/g/qlab/c/jypvuFAFj5Q/m/Qbg-Ykf7BgAJ

[Richard Williamson]

Oh interesting - I suppose then that the other way to fix it is to have a network cue used to start the group, since the network cue would break the timecode link?

--

Richard Williamson
www.richard-williamson.com
ric...@richard-williamson.com
07957 457 362

To view this discussion on the web visit https://groups.google.com/d/msgid/qlab/69675de2-93f1-49c8-b277-6cd7c47191fen%40googlegroups.com.

[micpool]

I don’t think a network cue will help in this instance.

Any cue that does not have a duration,  effectively has an infinite duration, as it doesn’t have an end time.

Mic

[glp...@gmail.com]

This change was a breaking change that is for sure. They need an option for a cue list to chase and lock or this cue list "triggers" but does not lock. I don't think it was fully thought thru. I get why they went and added that, but at least have the 2 options, trigger and freewheel vs lock. 

I may have to use another system which tracks timecode to send out a midi program change or note on cue to qlab, which I really don't want to do.

[Sam Kusnetz]

On Jan 19, 2023 at 7:10:22 AM, glp...@gmail.com <glp...@gmail.com> wrote:

This change was a breaking change that is for sure. They need an option for a cue list to chase and lock or this cue list "triggers" but does not lock. I don't think it was fully thought thru. I get why they went and added that, but at least have the 2 options, trigger and freewheel vs lock. 
I may have to use another system which tracks timecode to send out a midi program change or note on cue to qlab, which I really don't want to do.

Hello there

To begin with, “they” participate in this Google group, so there’s no need to talk about us like we’re not here. We’re also human people with feelings, like everyone else, and if you spend any time in this group I hope you’ll find that we’re very responsive to feedback from the wonderful and capable folks who use QLab and who generously share their time and expertise with others.

I don’t want to argue, but I can tell you that this change was indeed fully thought through. Chasing timecode, or locking to timecode, or whatever you prefer to call it, has been one of the most frequently requested changes in QLab for many, many years. I absolutely agree that it’s a breaking change, and that is the main reason we chose to wait for 5.0 to implement it, rather than introducing it sometime within the 4.x lifecycle.

Many people have told us in the past that QLab’s trigger-only behavior was different from all other timecode-receiving tools, was incorrect, prevented them from using QLab in situations that they would like to, and so on. From everything I’ve read and learned about timecode, its entire purpose for existence is to keep two or more devices synchronized over time. QLab’s trigger-only behavior failed to achieve that purpose! Discrete cueing was never intended to be within the scope of timecode, as far as I’m aware, and a need for discrete cueing was among the many reasons that MSC was invented.

I would love to know more about your situation. How is your timecode being generated? What is QLab’s role in your system? What is the exact result of QLab 5’s behavior that doesn’t work with your show? What about your setup makes sending discrete MIDI events (or MSC messages, or OSC messages) undesirable?

To be clear: I am FULLY prepared to agree with you! I simply want to learn more.

Best

Sam

—

Sam Kusnetz (he/him) | Figure 53

s...@figure53.com

[glp...@gmail.com]

Hi Sam

My apologies if I came off sounding abrupt, I certainly did not mean though. We love Qlab and the work you guys are doing on it and appreciate  the effort. No offense and sorry for that. 

It was pretty surprising after we loaded in our show that was working in 4 to all of a sudden cues going crazy in 5. We were shocked and everyone was immediately wanting to abandon 5 and go back to 4. hence our frustration. We use timecode in a trigger fashion and not always true sync or chase. Our shows are timecode based but with a lot of breaks for the actors. Music cues and timecode are all built on a Nuendo machine with a Rednet PCIEr Dante into Qlab, audio console, etc. Roll next music cue with smpte on word cues and keep moving for the next music cue. So we want a timecode trigger to play ambient sound fx just before the music / timecode stops to cover the breaks, but then on the next music cue block with timecode, fade out the sound fx . A lot of our cue programming might have a smpte timecode trigger, but on the next Play cue with qlab, we just have qlab stop the qlab playing sound fx with a referenced trigger, if that makes sense. 

We use Qlab as our main audio FOH show control computer. Play will send a midi play to Nuendo which plays the multitrack file with music and timecode on audio tracks for all departments to use. Qlab is listening to that audio track for time triggers in scenes. Mostly ambient stuff from Qlab to cover the "non music" scenes. 

A colleague may have found a work around in that if you trigger a cue with timecode, you need to stop the cue with timecode. That may be a workaround. We just need to figure out a new approach and get a grasp on the change and figure out the new programming scheme. Maybe a great solution would be in the cue list settings, to have the option to "Chase to timecode" or just trigger from timecode like in V4. 

Hope that helps clarify what we do. I did send a file in to support. Again, we love qlab and I meant no offense. 

[Sam Kusnetz]

Hi Gary

No offense taken! It’s very easy on the Internet to say things one way, and have them read a different way. I was not offended, I was only hoping to encourage more direct and personal communication, which it seems I have done!

I can absolutely understand how alarming it must have been to suddenly find different behavior. We try to make as much fuss about new features and changes as we can, but of course it’s impossible to be sure every detail is clear to every single person.

Thanks for describing your situation. Can I ask follow-up questions?

• Why are you using Nuendo for music playback, but QLab for other audio playback? Why not put the music in QLab?
• Nuendo can easily send MIDI messages, so what’s the reason not to use them for discrete triggers?
• If QLab is the main show control computer, why is it receiving timecode from Nuendo at all? It seems to me that this whole situation could be cleanly addressed by sending timecode from QLab to all departments, instead of using Nuendo as a sort of sub-controller for show control.

Again, no offense taken at all and thank you for engaging in this conversation!

Best

Sam

[glp...@gmail.com]

Hi Sam

Hopefully I can explain our setup.  Our shows are built by our sound designer usually starting about  9-12 months before rehearsals. This gives them plenty of time to get things roughed in. Most of the time in their studio. Our sound designer likes the way Nuendo operates. A lot of flexibility and power in a DAW. Plugins, processing, sheer track count. Our last show came in at about 1200 audio tracks. He likes not downmix things because it makes it a lot easier to adjust mixes and make edits and other things in the house during rehearsals. The Nuendo project with audio is brought to the house playback system a few months ahead for initial work and final mixing in the house. We bus it down to about 40 + channels which route to various speaker feeds, etc. 1 output is designated SMPTE and get's fed to a SMPTE DA Shaper, and on to departments. They like to keep SMPTE on Nuendo in case of changes. they can cut it, slide it, etc. works well. During rehearsals the sound designer manages the Nuendo mix from his programming station, but the FOH operator has screen to Nuendo access as well for locating, playback etc in Nuendo during rehearsals. Qlab is the control computer interface to Play Nuendo and cues using a Qwidget button box and the Ipad Qlab app. Qlab is managed and programmed but the FOH operators. We do a lot of manual sound fx from Qlab (punches, hits, other fx as needed) and Qlab is great at that. Qlab would not excel well at the massive track count and easy DSP power that Nuendo has, but is great for misc fx and also as our master "Play" computer and network triggers. 

We also do a lot of ambient fx during music / smpte breaks in the show. Rain, thunder, wind, crickets, etc and Qlab handles that extremely well. Those cues get triggered by incoming timecode from Nuendo. Usually a trigger for a qlab sound fx happens near the end of a Music / Smpte block like we like to call it, and the FX will run thru those "dry"times. Fade out cues happen when the next Qlab "Play Nuendo" command goes. Most times the fade out triggers  with timecode later in the next music cue or it may happen in the "Play" group command. The group cues plays Nuendo, and fades out the fx, triggers misc lighting cues and other things as needed.

We could use Nuendo with Midi program changes or Note or CC, but it was easier to read an incoming timecode stream and for the FOH operators to make adjustments to the cue timing in Qlab versus having a midi track in Nuendo, and asking the sound designer for a change, when he may be extremely busy during rehearsals working with the directors, producers. That is doable, but we found it a lot easier using incoming timecode and much simpler. 

We can find a way to make the new way work, it is just really different than how we have been doing it for the last 6+ years or so that we have been using qlab. 

Hope that helps clarify our setup. Let mw know if you have any other questions about it.

[Richard Williamson]

I know Mic says this won’t work - but I just tested, and creating an OSC network cue (with pure OSC rather than qlab cue since qlab cues seem not to include /start) targeting /cue/x/start at the machine in question allows you to set a timecode trigger on the network cue which then does a simple fire of the groups without any chasing going on.

I may be misunderstanding something but I think the above approach neatly recreates the old behaviour without a lot of additional overhead

--

Richard Williamson
www.richard-williamson.com
ric...@richard-williamson.com
07957 457 362

--

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/3a4644f2-6598-4b32-91d6-94fd78eabba9n%40googlegroups.com.

[glp...@gmail.com]

Thanks Richard for that idea. We will try that today. 

[Sam Kusnetz]

Hi Gary

That makes a lot of sense! I find any complex show control setup looks like total madness until you get into the details, and then it slowly becomes clear why things are the way they are.

Your setup is logical to me now, given your parameters.

It is also very much not the way timecode is “supposed” to work, which I hope you understand is NOT me saying that I think it’s wrong. You found a system that worked consistently, so you used it. I like that, and I applaud it. You’re cutting against the grain of how timecode is supposed to work, and QLab 4 was also cutting against the grain, so it was a perfect match.

I’m glad to know that you believe you can find a way to work within the Qlab 5 paradigm, which is, as far as we know, the “correct” way to use timecode.

Please do keep us posted about your progress. We definitely want QLab to be flexible and useful for timecode, and we are exploring this area of QLab actively.

Thanks again for your time and care.

[glp...@gmail.com]

Thanks again Sam. We will see how it goes!

[Rich Walsh]

I think the problem is though that if you have your Network cue be triggered by 01:00:00:00 then ANY timecode after that will trigger it – which is counter-intuitive and, er, awkward. We’re looking for a way that cues without duration will only fire when they see their exact trigger timecode message, whilst those with duration will work out where they should be based on incoming timecode and jump to there.

To me, that would be more consistent with what happens when you jump around in a DAW: you don’t expect to hear all the zero-duration MIDI notes from before your new timeline position when you hit play.

Rich

[Sam Kusnetz]

On Jan 19, 2023 at 11:22:16 AM, glp...@gmail.com <glp...@gmail.com> wrote:

I know Mic says this won’t work - but I just tested, and creating an OSC network cue (with pure OSC rather than qlab cue since qlab cues seem not to include /start) targeting /cue/x/start at the machine in question allows you to set a timecode trigger on the network cue which then does a simple fire of the groups without any chasing going on.

/start is indeed available using the QLab 5 network device description, as the attached screen shot demonstrates.

Set Type to “Cues”, Target Cue Type to “All cue types” and then Command to “Start”

[Richard Williamson]

Ah - now that is interesting, and definitely not what I would expect (or how I think timecode should work), this is how hog 4 (from memory) does things and caused a show I was involved with to go very wrong when some cues were moved around. Personally I would strongly feel that this choice was a mistake, as it would make qlab useless as a central show control device (where I add network cues chasing timecode to fire additional pieces of kit) 

--

Richard Williamson
www.richard-williamson.com
ric...@richard-williamson.com
07957 457 362

--
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/22B48A3E-A42F-427F-A4E7-73F80223CBBA%40mac.com.

[Chris Ashworth]

We’ve been extensively discussing the topic in Figure 53 Slack this morning, and are currently exploring the idea of adding a per-cue-list option to set a window of time prior to a newly incoming timecode stream within which any cue triggered by timecode will still be triggered.

Conceptually, it would be a setting like this:

"When timecode starts, start zero-duration cues up to {xxx} seconds before first frame"

Thus allowing you to pick up a chunk of the timecode timeline prior to where you’re starting, set per cue list.  

You could then either completely ignore zero-duration cues prior to the timeline start time, or go back arbitrarily within the timecode “timeline” to pick up either all or some previous cues.

To our eye this might do the trick, but I welcome any feedback about problems it might cause 

-C

[micpool]

I think there are 2 things getting confused here. Before QLab 5 we have regularly debated the way that QLab has fired all the MIDI and start cues etc. in a timeline group or a sequence of cues when a group is loaded to time. The logic is that doing this will allow all your external lighting consoles, outboard effects and console program changes etc. to be in the correct state. Sometimes  the net result of this was MIDI device overload, external devices not processing the incoming MIDI fast enough etc.

This behaviour is consistent with how these zero duration events are now being treated  in a QLab 5 cue list that is now syncing to TC (in the same way as a group being loaded to time in QLab 4 was syncing). The difference is now the whole list is syncing as one giant group, so if we had 96 cues or Timeline groups of cues  being triggered by TC  with start times offset by  15 minute intervals, which wouldn't be unusual in a lot of set ups potentially playing the TC for Cue 96 would start every event with zero duration in cues 1 to 95.

There is a straightforward fix to stop audio  and video playing outside the bounds of their  timeline group, and that is to include a stop cue targeting the group with a pre wait where you want to set the boundary.

In the attached screen recording I have 3 Timeline groups  with TC start at 1:00:05.00, 2:00:05.00, 3:00:05.00  Each group contains an infinitely looping audio cue, a MIDI note cue and a stop cue with a pre wait of 59 seconds to define the end boundary of  each group

The audio cues do not fire on higher timecode values.

However all the Midi Cues (zero duration cues) from the entire cue list are spat out at once every time a higher timecode value stream starts to be received

This is exactly what would happen if instead of being in a timeline synced cue list the cues were in QLab 4 enclosed by a timeline group that was loaded to time.

Perhaps this gives a clue as to how this might be tackled, what would the downside be if before spitting out all the zero duration events, any that were in TC triggered groups that were stopped at the incoming TC value were not output?

Mic

[micpool]

And the workspace for the above

[micpool]

On Thursday, January 19, 2023 at 2:55:26 PM UTC glp...@gmail.com wrote:

A colleague may have found a work around in that if you trigger a cue with timecode, you need to stop the cue with timecode. That may be a workaround. 

Setting boundaries for cues with durations (including infinite durations)  doesn't require  the cues to be stopped by TC. You can just use a stop cue with pre wait, as in the screen recording in my previous post. This is much easier to handle as you only need to set the TC trigger on the timeline group, and you can copy the group and only change 1 TC value and edit the contents of the group. However any zero duration cues in the list prior to the incoming value will all fire 

Mic

[glp...@gmail.com]

Thanks Micpool. I will look at your boundaries file when I get to the theater.