Timecode

[Rich Walsh]

Asking for a friend, as they say…

Anyone know of an affordable alternative to https://sononum.net/horae to receive LTC and regenerate MTC for QLab as QLab 4 doesn’t freewheel (I think)? For troubleshooting purposes… (I’d always stick a Rosendahl MIF4 inline myself these days).

What can cause “waiting…” other than:

• No signal
• Signal too low
• Signal distorted
• Signal corrupted (eg: MTC via some nasty merge box)

(As an aside, if you wanted v4 just-trigger-don’t-chase behaviour in v5 could you do it? I know we spent years asking for chasing; sorry!)

Thanks!

Rich

[micpool]

On Friday, November 25, 2022 at 11:25:03 AM UTC Rich Walsh wrote: 

if you wanted v4 just-trigger-don’t-chase behaviour in v5 could you do it? 

Timecode trigger on a start cue?

[Rich Walsh]

That’d be it. Thanks.

Rich

[micpool]

On Friday, November 25, 2022 at 11:48:53 AM UTC Rich Walsh wrote:

That’d be it. Thanks.

Unfortunately, although it seemed a logical solution, of course it's not!! 

Start cues triggered by TC behave the same way as MIDI cues, so if your start cues are in a cue list synced to TC they will chase to time in the same way,.

 i.e if you had 4 start cues with TC triggers   1s 2s 3s 4s

and ran the TC from 0:00:02.05

the first 2 start cues would trigger immediately  and  start their targets which would sync to their correct offsets

and then cues 3 + 4 would trigger on the running TC starting their targets in sync

 

Other  cues with TC triggers  e.g MIDI  would also start in the same way.

So, in conclusion I'm not sure there is a way to emulate the old behaviour, and the new chasing behaviour ,although brilliant, can have a lot of unexpected consequences,, until you have really got to grips with it in depth.

Example workspace (which uses IAC Bus 1) and screen recording attached

[micpool]

The behaviour of start and MIDI cues in a QLab5 list triggered by timecode is pretty much the same as how they behave in a loaded to time group cue in QLab 4. i.e cues outside the group, targeted by the start cues in the group, also load to time. And MIDI cues outside the group that are targeted by start cues in the group all fire to send all the MIDI that would have been sent up to the load time as in the attached screen recording.

Mic

[micpool]

On Sunday, November 27, 2022 at 1:53:17 PM UTC micpool wrote:

cues outside the group, targeted by the start cues in the group, also load to time. 

While hunting the elusive workaround for getting QLab 4 timecode behaviour on a single cue in QLab 5 (which I am coming to the conclusion might not  exist), I have been struck by the magical abilities of start cues to load their targets to time even if their target cues are in a different list.

This extends to loading the start cues to time and their targets following or, if the start cue has a TC trigger, or is in a group with a timecode trigger, causing its target to also chase the timecode. The start cue also inherits the duration of the target cue although this is only visible if you load it to time (as the maximum value on the load to time slider)

This is like some other-worldly  quantum entanglement and is impressively implemented, as I can't break it. It also seems to be undocumented.

It's also worth noting that this means that a start cue targeting cue "1" is not synonymous  with the  OSC message  /cue/1/start as this will always start cue 1 from the beginning.

OSC cues also behave like MIDI cues,  any cues that are in a group,  that is loaded to time beyond their pre-wait times  and started , will all fire together . and the behaviour is similar with chasing incoming TC.

I think MIDI and OSC cues are quite difficult to deal with in a group that chases timecode, as they in effect have an infinite duration,  Whereas a still image can be given a duration so it won't start when a group with a later TC value is triggered by incoming timecode, infinitely looped cues can be changed to play x times loops, and hold at end videos can have fade and stop cues, within the group, and I can't think of a way of overriding the effective infinite duration of  these cues, without an option to have them behave as in QLab 4 i.e timecode match triggering only.

The net result of this makes it difficult for users organising their cue lists as sequences or songs in timecode triggered groups at 1 hour intervals, which is a fairly common means of achieving this separation, as song 11 at 11:00:00.00 is going to trigger all the OSC and MIDI cues  in songs 1 -10.  

This behaviour is of course similar to what happens in a timeline group in QLab 4+5. But the effects of these OSC and MIDI storms extending through a complete cue list  may well be more overwhelming for the system, and more importantly, the MIDI and network devices hanging off them .

I think a similar issue may arise with lighting cues, but I haven't fully thought that through.

Mic

[Richard Sillitto]

As a little aside, the Destripilizers are brilliant at reshaping dodgy timecode and buffering whatever you throw at them to a consistent level.

I don’t do a job that requires timecode without one these days. It’s truely incredible how much gain you can screw into the feed into the box, and it merrily sorts it all out and produces lovely clean timecode on the output at a respectable level.

https://brainstormtime.com/products/sr-112/

Rx

E: ric...@yoursoundsolution.co.uk
M: 07931 955149
W: www.rs-sound.co.uk

--
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/12038e0d-ea48-47bf-b319-8aedb8ae94f9n%40googlegroups.com.