Cue cart and duration

[Dominik Wild]

I'm using QLab at sports events. By default I want to show the scoreboard on the videowall and in order to show videos with QLab in certain game situations the operator has to switch channels on the external video mixer. When doing that manually in the heat of the moment sometimes our operator forgets to switch the channel back afterwards.

I have already created a group cue which automatically switches the video mixer's channels back and forth using midi cues. Because there are a lot of videos, I need to fire them from cue carts. But as I can't directly use a group cue in a cue cart I have to use a start cue which obviously doesn't have a duration. The problem is that certain videos require exact timing from the announcer, so having the progress bar would make things a lot easier.

Is there any way to fire a group cue from a cue cart and still have a progress bar?

I wouldn't mind setting the duration manually. I already tried firing the group cue using a network cue with a duration, but that just constantly fires the group cue and as a result brings down QLab.

[micpool]

the simplest way fro your application is just to have the active cues window open

Mic

[Rich Walsh]

You can’t re-trigger a cue while it’s running, so all you need to do is give your Group Cues a duration that is longer than that of the Network Cues – one way of doing that is to add a Post Wait to them (or put a Wait Cue inside them).

I was wondering if you could do something clever with the 1D fades – by fading the cue number away from the value you needed – but I couldn’t get it to work how I’d imagined.

Another way would be to have your Group Cues contain a Start Cue that starts a Wait Cue next to your original Start Cue in your cart.

You could also use a Network Cue to fade the name of the Start Cue as a countdown, eg:

/cue/1/name "#v#"

Rich

--
Contact support anytime: sup...@figure53.com
Follow Figure 53 on Twitter: https://twitter.com/Figure53
User Group Code of Conduct: https://figure53.com/help/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/a473897e-c357-4c79-9afd-e0a3c8f2a6f1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Andy Dolph]

One solution that occurs to me is to use an additional monitor (or a syphon feed that shows in a separate window) that plays a 2nd video with the countdown and any other cues you need to feed to the announcer - that would essentially provide a status display.  I'd just make one timer countdown video starting from longer than you expect to ever need, than just start it cued at the right place...

Andy

--

Contact support anytime: sup...@figure53.com
Follow Figure 53 on Twitter: https://twitter.com/Figure53
User Group Code of Conduct: https://figure53.com/help/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+unsubscribe@googlegroups.com.

[Chris Ashworth]

On October 18, 2017 at 3:17:41 PM, Rich Walsh (rich...@mac.com) wrote:

You can’t re-trigger a cue while it’s running,

(Unless you set a “second trigger action” of “hard stops and restarts” in the triggers tab.)

-C

[Dominik Wild]

Despite being a bit hackish, this is very helpful, thanks.

It seems to be important that the group itself has a post wait otherwise the group is not considered running.

Having a start cue and a wait cue inside a group cue without post wait caused a flickering green arrow next to the start cue.

Group cues are a great feature but I wished the duration of groups would be more intuitive.

[Rich Walsh]

If you use a “start all” group then the duration of the Group Cue is displayed in the “action” column. I can’t recreate what you describe unless I don’t make the Wait Cue part of the sequence within a cue: so it’s not actually fired. As long as the Wait Cue is fired by the action of starting the Group Cue, the Group Cue can not be re-triggered until the Wait Cue has completed. (You can set second trigger options to stop it, but not re-trigger it.)

Didn’t realise I’d spent the last 8 years “hacking” QLab. Thought I’d been working out what it could do if you put your mind to it…

Rich

To view this discussion on the web visit https://groups.google.com/d/msgid/qlab/1da1c50d-7abd-45fc-ba8a-a035062802e9%40googlegroups.com.

[Dominik Wild]

I tried a "Start first child and enter..." group which obviously doesn't work in that case. That's what I actually meant by "hackish", I do want a sequential flow of cues but have to use a "Start all children simultaneously" group, which doesn't seem logical to me, it somehow feels like a workaround. I'm a software developer, we usually define a "hack" in the sense of a solution which gets the job done, but in a rather inelegant way. That's not to say there is a more elegant solution, but in my opinion the handling of groups could be improved in QLab.

[Sam Kusnetz]

On October 19, 2017 at 8:37:34 AM, Dominik Wild (domini...@gmail.com) wrote:

I tried a "Start first child and enter..." group which obviously doesn't work in that case. That's what I actually meant by "hackish", I do want a sequential flow of cues but have to use a "Start all children simultaneously" group, which doesn't seem logical to me, it somehow feels like a workaround. I'm a software developer, we usually define a "hack" in the sense of a solution which gets the job done, but in a rather inelegant way. That's not to say there is a more elegant solution, but in my opinion the handling of groups could be improved in QLab.

Hello Dominik

The reason that Group cues only have durations if they are set to “start all children simultaneously” is because for all other modes of a Group cue, the total duration of the Group is non-deterministic. If you have a “start first and enter” Group, then the playhead enters the Group and awaits another press of the GO button, unless of course you’re using auto-follows and/or auto-continues. Since it’s possible (even likely) that the playhead will rest on a cue inside that Group, waiting for the operator to hit GO, there’s really no way to know in advance how long the Group will be running.

In the case of “start first and go to next cue” Groups, you might have an Audio cue inside the Group which has an unknown number of loops, or an infinite loop that awaits a Devamp which comes from outside the Group. Again, there’s no way to know how long the Group will last.

In a “start all children simultaneously” Group, while it’s still possible to have unknown durations, the baseline case is much easier to guess: the duration of the Group is equal to the duration of the longest child cue, including its pre-wait.

So, using a “start all” Group with pre-waits on child cues is not hacky at all, it’s the exact intended solution for a situation like this.

Best,

Sam

—

Sam Kusnetz | Figure 53

s...@figure53.com

[Rich Walsh]

If you’re triggering these groups in an entirely random and non-linear way from a cart, how is there any concept of a sequential flow of cues?

I don’t think worrying about the progression of a non-determinate number of playheads through the cues of several groups is a generally useful approach, and particularly not in your use case. Treat each group as a self-contained handler that will do everything it needs to do when called; a start all group is the most elegant way of doing that; only very, very rarely have I ever needed any other mode of group cue.

Rich

To view this discussion on the web visit https://groups.google.com/d/msgid/qlab/84f84b29-7696-46a4-908a-57280bc0c6b6%40googlegroups.com.