Various Bugs and discoveries

[Kinetic Screen]

Ok I'm compiling a big list of things I'm discovering as I (perhaps ill advisedly) plan to use v5 for  a performance Sunday week. Some of these are bugs, others are changes to expected behaviour from previous versions, which may or may not be an issue as such.

1. NDI Output doesn't actually "Keep rendering between cues" even when selected. Shortly after stopping playing anything, the NDI video appears to stop having any content in it. The stream still exists on the network, but it contains nothing, and certain NDI playback devices will stop sending a video signal, which takes several moment to recover once a cue is played. This is particularly glaring when the attached monitor starts showing "Input lost" or whatever.

At the moment the workaround for this is to always have at least a black still active - but presumably this is what the "Keep rendering" function should be doing.

This might be related to the problem I mentioned elsewhere about the NDI Output's audio having some kind of sync sample rate issue for the first second or so of a cue's playback.

2. Change in how updated files behave when running as cues. This is a pretty niche application, but in previous versions if say a Photoshop file was being presented as a cue, and while it was active that file was updated and saved in photoshop, Qlab would automatically a few seconds later reload the updated file.

One unexpected disadvantage of this was that when the cue updated, it would also revert back to its original geometry, so if you had since changed its opacity or geometry via a fade, this would snap back to the original values.

In v5 updating a file is ignored by Qlab, until you manually reload the cue

This change isn't necessarily for the worst, but it wasn't expected, so changed the way I implemented doing something screwy with a scoreboard.

The fix was the add a cue that stops and loads the cue to update it - with which I ran into a problem that seems similar to the elsewhere mentioned load at time unreliability, which is that I could only get this to work reliably once I had a 0.1 pre-wait on the load cue after the stop cue.

This was a similar fix that was needed when getting a video that is playing to load at a particular time reliably.

3. NDI sources continuously pull in full data in the background, regardless if they are playing, pre loaded or inactive. Whereas the issue with NDI outputs is that they aren't maintained while not being actively played to, the NDI inputs have the opposite problem, and while there is an advantage to this (instant cue-ability that works really nicely) it does add a significant network overhead that quickly adds up once multiple NDI sources are added. It would be good if this could also be toggled (i.e. "Stop receiving when no cues active") to give the option of lower system utilisation, obviously at the expense of having it take a moment to reestablish the NDI feed when cued (which could be preloaded manually by adding a load cue). 

4. Allow the reordering of video Stages, as their position appears to affect cues layering when reusing video devices.

Here's the scenario. I have multiple screens for this show, including one that is Portrait (1080x1920) and one that is landscape (1920x1080). We have some fake TVCs that are in 4:3 format, so to make things easier I've created a Stage that is 4:3 (1440x1080) Which I then have sent to both screens. I use the warping function to resize the 4:3 content to best display on both screens.

However, I also have my usual Stages for each screen individually. So if I have some content playing on both of them, and I want to overlay content via the 4:3 Duplicate, because that 4:3 stage is 'under' the other stages it doesn't matter what I set the video layer to, it will always be hidden by any content on the Stages above it.

[Sam Kusnetz]

Hello “Kinetic Screen”

NDI Output doesn't actually "Keep rendering between cues"

This is in error, and we will explore it. Thanks for pointing it out!

This might be related to the problem I mentioned elsewhere about the NDI Output's audio having some kind of sync sample rate issue for the first second or so of a cue's playback.

It is not related. We are working on that issue.

Change in how updated files behave when running as cues. This is a pretty niche application, but in previous versions if say a Photoshop file was being presented as a cue, and while it was active that file was updated and saved in photoshop, Qlab would automatically a few seconds later reload the updated file.

This is indeed how it works, and we do not perceive this to be a bug. In fact it would be very challenging to reimplement the old behavior!

We also do not recommend using Photoshop files; the PSD file format is a bit terrifying and unexpected things can happen if you use them.

One unexpected disadvantage of this was that when the cue updated, it would also revert back to its original geometry, so if you had since changed its opacity or geometry via a fade, this would snap back to the original values.

This is one solid reason why we don’t want to go back to the old way.

3. NDI sources continuously pull in full data in the background, regardless if they are playing, pre loaded or inactive.

We made this choice in order to make it possible to run a Camera cue which uses an NDI source at any time, without needing to do anything specific to “prepare” it. Generally speaking, QLab’s design philosophy is to embrace the possibility that any cue might be run at any time, without warning. The cost of this level of preparedness is an increased use of system resources, but our feeling is that system resources are there to be used!

It would be good if this could also be toggled (i.e. "Stop receiving when no cues active") to give the option of lower system utilisation, obviously at the expense of having it take a moment to reestablish the NDI feed when cued (which could be preloaded manually by adding a load cue).

I suppose this is worth considering, but adding toggles like these makes QLab harder to test and harder for novices to understand, both of which give us pause.

4. Allow the reordering of video Stages, as their position appears to affect cues layering when reusing video devices.

While we do want to allow reordering of the video stage list, their order does not affect layering. Rather, stages have their own layer scheme which exists “above” the cue layer scheme. To change the stage layer, go to Workspace Settings > Video > Video Stages and click the Edit button next to the stage you want to edit, then adjust the layer in the top center area of the stage editor window.

If you have two stages which use the same actual output pixels, all the cues on the higher-layered stage will layer on top of all the cues on the lower-layered stage. All you need to do is set the "4:3 Duplicate" layer to a higher number than the “Projector” and “Portrait Screen” layers and you should be all set.

I’ll take this time to say once again that for bug reports, it really is much easier for us if you send them to sup...@figure53.com. Messages sent to that address filter through a system that lets us easily track and categorize reports, group similar reports together, and so forth. Also, to be perfectly frank, it feels kind of lousy when people make basic bug reports in this public forum, a bit like a director waiting until the whole cast is gathered together to point out that someone dropped a line.

All my best

Sam

—

Sam Kusnetz (he/him) | Figure 53

s...@figure53.com

[Kinetic Screen]

Hi Sam, thanks for the detailed reply. And apologies I genuinely didn't realise that this forum wasn't the best place for bug reports.

[Sam Kusnetz]

On Sep 30, 2022 at 5:35:03 PM, Kinetic Screen <kinetic...@gmail.com> wrote:

Hi Sam, thanks for the detailed reply. And apologies I genuinely didn't realise that this forum wasn't the best place for bug reports.

Hi Kinetic Screen

No worries at all! I’m quite sorry if I came off too sharply, too. As we say in our company Slack, “text is hard” and it can be easy to read something with a tone that was not intended. I think it’s likely that I read your message with a tone that you did not intend, and I think I probably responded with more emotion than I ought to have.

We really do appreciate the feedback we receive from folks like you. QLab is so much better for it.

Best