Video cues in Playlist Group with Hold at End

[rosario calvagna]

Hi everyone,

I would love to have a feature for Playlist Groups.

When a Video cue is inside a Playlist Group and “Hold at End” is enabled, it would be very useful if Auto-Follow were automatically ignored or disabled.

At the moment, even with “Hold at End” enabled, the Auto-Follow still advances the playlist, which makes it difficult to use a Playlist Group as a manual video playlist/player.

My expectation would be:
if a cue is holding at end, the Playlist Group should wait on that cue until a manual “Next” or GO command is received.

Thanks!

[Luca Telleschi]

I think is not how playlist group is intended to work.

Try making a group and use the peer function in the trigger tab.

L.

---

Luca Telleschi ____________________________ Via Pietrazocca 32 - Verucchio (RN) +39 349 111 51 26 telleschiluca@gmail.com

--
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/f36a2c00-db35-4e1f-8aac-71db35100a12n%40googlegroups.com.

[rosario calvagna]

Hi Luca,

Yes, I know that this is probably not the intended behavior of Playlist Groups.

The reason I was thinking about it is because Playlist Groups already feel very close to a media playlist/player workflow for video playback.

In a way, Video cues set to Loop already behave similarly to what I’m describing, and static Image cues as well. This would basically complete the last missing type of video behavior needed to create very immediate crossfades between videos with a Playlist Group.

But maybe there is also a good reason why the current behavior is the correct one and should remain as it is. If that’s the case, I’ll simply continue working the way I always have.

To view this discussion visit https://groups.google.com/d/msgid/qlab/CAN6kdn1xOqtd7wPh3MyZ_dhwD5seiwpR-qtird3PG838yo7uMQ%40mail.gmail.com.

[Sam Kusnetz]

QLab itself is already a manually advancing play list. The point of the Playlist mode of Group cues is to offer a way to do automatically advancing play lists.

If what you want is to manually advance through cues, but have them automatically crossfade, then put those cues in a cue list together, or in a Start First and Enter Group cue, set them to fade and stop peers (in the Triggers tab) and you’re all set.

Best

Sam

—

Sam Kusnetz (he/him) | Figure 53

s...@figure53.com

[rosario calvagna]

Sam, thanks for the reply.

I use “fade and stop peers” very often, but it doesn’t completely solve what I’m trying to achieve, because:

- I need to place all Video cues on the bottom layer (which is not really a problem)

- the first cue I trigger never gets an automatic fade-in

- it works well with videos that are in fill stage mode, but as soon as I start using cues mapped to portions of the screen, the result becomes visually unpleasant

I’m attaching a short video example to show what I mean.

In the demo, the third and fourth groups behave correctly for my use case, but I think you can agree that the fourth group — which achieves the same result using only 4 cues — is much faster to program.

So I’m wondering: what am I missing?

 Screen Recording 2026-05-13 at 22.51.09.mov

--

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/CAOOK5Ab47%3DM_S%3DygFoeOVhYgxGKkVKR_g66V1EkQMSB8Mkt86g%40mail.gmail.com.

[Richard Williamson]

I for one would agree that this would be useful - playlists are great for quick and dirty show programming, and if an option to "auto continue" or similar was added to the playlist settings it would mean many corporate shows could be programmed in half the time

 

Richard

--

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

To view this discussion visit https://groups.google.com/d/msgid/qlab/CAPgyD5Ypkyw6P1vC7-t67brsqiLraLJT0PCtV85LEa4F71W8nQ%40mail.gmail.com.

[rosario calvagna]

Yes, exactly.

I think the option to choose whether or not the Playlist Group applies automatic auto-follow behavior, directly in the Playlist tab, would solve the issue at the source.

I believe this is what Richard was referring to.

To view this discussion visit https://groups.google.com/d/msgid/qlab/fa3f76c5-b599-4179-91e8-7bf6a3e939bb%40Spark.

[micpool]

I think there are two distinct issues here.

The first is the anomaly that a video cue with zero duration  (i.e. a still image) in a playlist group behaves as if it has infinite duration, and a video cue with a duration but with hold at end, (making it theoretically a cue with infinite duration) retains the duration of the cue as if hold on end had not been selected. If you preview a video cue with a hold on end. it will fade out at the end over the crossfade time set for the playlist group, rather than hold at end. But if you preview a still image with zero duration, it plays for ever. (or until another cue in the playlist group is played or previewed).

The other issue is that when you trigger a playlist group, or a cue within a playlist group, the playhead goes to the next cue, which is the cue after the playlist group, and does not enter the group even if the playlist consists entirely of video cues with zero duration. This is the issue raised in a thread from a couple of days ago:

https://groups.google.com/g/qlab/c/PAFTiyHU0m4

It's possible to script a mode of operation that makes QLab behave as Rosario would like for still images , but because of the first anomaly described above this will not work with videos with hold on end ticked.

MIc

[rosario calvagna]

Hi Mic,

The first anomaly is exactly the part that I can’t find a way to solve.

What I’m not sure about is whether this is an intentional behavior or something that should maybe be reconsidered in qlab.

I saw the script you posted in the other thread and I found it very interesting.

Actually, I usually use the second trigger function, which in Playlist Groups can be set to “next”.

To view this discussion visit https://groups.google.com/d/msgid/qlab/77384839-2105-4601-a782-b49f419d9cf9n%40googlegroups.com.

[Sam Kusnetz]

On May 13, 2026 at 5:25:51 PM, rosario calvagna <rosario....@gmail.com> wrote:

In the demo, the third and fourth groups behave correctly for my use case, but I think you can agree that the fourth group — which achieves the same result using only 4 cues — is much faster to program.

So I’m wondering: what am I missing?

With much respect, I think that what you’re missing is that “fastest possible cue programming speed” is not the only factor to take into consideration.

The designed purpose of the Playlist Group is to allow you to quickly and easily create a playlist; a series of cues that play automatically one at a time. The behavior of still image Video cues in a Playlist Group is a consequence of the behavior of still image Video cues in general, which existed long before Playlist Groups were created.

We’re always happy to receive feature requests, but it’s easiest for us to understand and prioritize feature requests that center around something you’d like to do in QLab but cannot.

I very much appreciate this whole conversation!

[rosario calvagna]

I completely understand that programming speed and reducing the number of cues should not be the only goal in QLab’s design.

But, as you also explained, before the introduction of Playlist Groups it was already possible to build sequences of cues that automatically advanced one after another. And yet a dedicated feature was introduced specifically to make that workflow simpler and more immediate.

That said, the point of my observation is not really to request a completely new feature.

As MicPool also pointed out, there seems to be a certain inconsistency in the behavior of cues inside Playlist Groups: cues with finite duration automatically advance the playlist, while cues with theoretically infinite duration (still images, looping videos, etc.) do not.

Videos with “Hold at End” enabled would seem to belong to this second category, yet they still behave as finite-duration cues when it comes to playlist progression.

So I was wondering whether there is a specific design decision behind this behavior, or whether it is simply a technical consequence that was never really reconsidered.

--
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/CAOOK5AZO-snVEgbd6hCt3LNcF2-N9VeOzYLD8DVkfh-3hy7wyA%40mail.gmail.com.

[Sam Kusnetz]

I don’t really think it’s an inconsistency… things which are different behave differently.

But I also agree it could feel better if “hold at end” Video cues were treated the same way as still image Video cues.

Best

Sam

—

Sam Kusnetz (he/him) | Figure 53

s...@figure53.com

To view this discussion visit https://groups.google.com/d/msgid/qlab/CAPgyD5ZDw76rUZ%3DDwDHCBJeYqLGqF97zo%2BN472oUpy_%3DvC0HRQ%40mail.gmail.com.

[Paul]

I think the OP is mis-understanding how Playlist cues are designed to work. (and how most people actually use them). To use the hold at end you would more likely use a Start First and Enter group.  Of course you could have another mode of group cue - something between a playlist group and the start first group - that would do what the OP wants. 

Still it's possible to program that behaviour now with the start first, it's just a bit more work but  if necessary automate the programming of that using some scripts. After all that is how everyone did it before playlist groups were a thing - with fade in cues. 

As with everything is a balance of development effort vs maximum benefit to greatest number of users.

[micpool]

I think you underestimate the OP's knowledge of the program!

What they are using is a documented feature of QLab 5

https://qlab.app/docs/v5/fundamentals/group-cues//#second-triggers

Second Triggers

By default,  Playlist Group cues automatically play through their children sequentially, starting each child cue when the previous child completes. However, you can also set a  Playlist Group cue to advance to the next child cue, or step back to the previous child cue, using the Second Triggers pop-up menu in the Triggers tab of the inspector.

If a  Playlist Group cue receives a  while one of its children is playing, and its second trigger behavior is set to plays next, the  Playlist Group cue will start the child cue after the one that's currently playing, crossfading if that option is set, and looping around from the last child cue to the first if that option is set.

If the behavior is set to plays previous, a  will cause the  Playlist Group cue to start the child cue previous to the one that's currently playing, likewise respecting crossfading and looping settings.

These options are particularly useful when the  Playlist Group cue contains cues with an indeterminate length, such as an infinitely looping  Audio cue, a  Video cue targeting a still image, or a  Text cue.

So what they are doing was envisaged by the developers to be 'particularly useful' in doing that, and is actually a brilliantly  quick way of making a bunch of cues into a crossfading cue list, without worrying about fade peer layers, or things being different sizes or being transparent like text.

The problem the OP has is that 'hold at end' on a video cue is ignored. The first solution that came to mind was to loop a short slice at the end of the video, but looping a slice only defeats the autocontinue if the looped slice is at the beginning.

A fully looped video works exactly the same as a still or a text cue.

Unless I am missing some other use for these features being included in QLab 5, I think the OP is being  reasonable in concluding  that there was some intention from the developers to use playlists in the way the OP wants to, and the fact a looping video, or a video with a looped first slice, works differently to a video with hold on end or a looping slice at the end, isn't entirely consistent!


Mic

[micpool]

On Thursday, May 14, 2026 at 9:44:11 PM UTC+1 micpool wrote:

 the fact a looping video, or a video with a looped first slice, works differently to a video with hold on end or a looping slice at the end, isn't entirely consistent!

And just to reinforce my suspicion that these inconsistencies may be accidental.....

There is another video cue setting that WILL result in a hold on end behaviour. 

To make this you have to first put a video cue into an infinite loop

then add a slice in the last frame of the video cue.

Et voila!


Screen recording attached

There's even a whole raft of OSC methods to allow you to do clever things with the playlist e.g

/cue/{cue_number}/playlist/next

/cue/{cue_number}/playlist/previous

/cue/{cue_number}/isNextInPlaylist

cue/{cue_number}/secondTriggerAction {number}
0 - Do nothing
1 - Panic
2 - Stop
3 - Hard stop
4 - Hard stop & restart
5 - Devamp
6 - Playlist Next
7 - Playlist Previous

[rosario calvagna]

Thanks Mic for the always valuable insights you share.

I already regularly use the techniques for advancing cues inside Playlists via Second Trigger or OSC, but I think it was very useful that you also wrote them here in the thread, so they can be immediately available to anyone else interested in the topic.

Regarding the first point, I found the workaround you showed very interesting: in practice, you manually recreated a Hold at End behavior, but in this case the Playlist logic becomes consistent again.

--
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/fb2fc43d-7bb8-44c3-a26c-8566e4bb761cn%40googlegroups.com.