Auto-load

[fg]

I've not noticed much difference having Auto-load checked, is it a good idea to have all cues set to Auto-load by default, or are there downsides ?

[Ivan Birthistle]

I set auto-load as default for a couple of reasons.

Aside from the practicality of actively loading cues ready to fire, being able to see that your next sequence is intact and ready to go is my main one.

On Tue, Aug 9, 2022 at 11:13 AM fg <friendl...@gmail.com> wrote:

I've not noticed much difference having Auto-load checked, is it a good idea to have all cues set to Auto-load by default, or are there downsides ?

--
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/c0720f2c-2f9d-4c23-926d-c1804ba9412an%40googlegroups.com.

--

Ivan Birthistle

Head of Sound

The Lir,

Pearse St.,

Dublin 2

(01)8964536
087 6699192

www.thelir.ie

Registered Charity Number: 20076689

[fg]

Cheers, I'll set it as default

[micpool]

Autoload is essential when running timeline groups with pre waits, or timeline groups that contain cues both with and without audio tracks that need to run in sync.,

Autoload will also minimise the time between pressing GO and seeing the result. If you are only playing single files on a modern computer, you won’t see much difference. But if you had  a timeline group with 24 audio cues, e.g as stems of a backing track, then you would get a better go button response with them loaded. (However it’s probably worth pointing out that, if the cues in the group all start together at 0 seconds, then they will be in sync with each other regardless of whether they are loaded or not, the only difference will be the time to start, and none of the tracks will play until all the ducks are in a row, and QLab has the ability to clock them all from the interface audio clock)

Autoload off is useful in the following scenario and similar situations.

A series of consecutive cues start the playback of media, resulting in several media files playing back simultaneously. The cue after the final cue of this sequence is not required for a few minutes after the first sequence completes, but is a timeline group with lots of simultaneous sound and or video cues being played back simultaneously.

If autoload is on for this group, then when the last cue of the first sequence is played, the loading of the complex second sequence, can disrupt playback of the first which might result in dropped frames, . In this instance you would deselect autoload and use a load cue, following on from the completion of the first cue sequence  to load it.

Another situation where you would need to manage loading  is this:

You have a soundtrack for a four hour immersive environment, that is started with a single Go, and runs as a series of 1000 timed audio cues, either in timelines or with autofollows and continues.

Loading a thousand cues simultaneously, or having a thousand cues preloaded, is likely to affect the performance of your computer. So you need to manage the loading of cues in manageable blocks, having regard for sync requirements, and number of simultaneous loaded cues, by using autoloads, and also load and start cues, to prevent the entire cue list loading at once

Mic

[fg]

Thanks Mic. Let's say I have lots of cue lists, 1 of them is particular heavy (Camera Cues, Multiple overlays of imagers etc..), but doesn't appear till the end of the show. 

Would it be wise to not have Auto-load as default, and just set the cues in that list as Auto-load ?

[micpool]

I would just leave it on in the cue templates  as a default.

If you get any problems with playback hiccuping at the time other cues are loading, you will know what to do from my previous post.

As with questions like how many audio or video cues can I play simultaneously,, there are so many factors that can affect this, that it’s impossible to generalise.

Most users keep it on as the default and never give it a second thought,

Mic

[fg]

ok thanks Mic, my default was Auto-load: disabled btw

[jimsta...@zoho.com]

  In the shows I've been running, autoload was not preferable.

Many on-the-fly changes to the show might leave several cues preloaded.

  Using groups inside groups with sometimes three or four synced audio tracks and always two or more visual elements.

Two-surface crossfade loops for example. (Thanks for that, Mic! There must be a hundred in my show file)

  Other than trying to edit on an old laptop, the worst handicap for cue starting to me has been still images.

Converting JPGs to ProRes 422 Proxy videos and using hold at end fixed that.

  If using auto-load in a "less predictable" and fast paced show, a hotkey to unload all preloaded cues would be useful.

Jim

[fg]

that's interesting. Also ProRes videos instead of JPGs?? Wow, I didn't know that

[Sam Kusnetz]

Hi fg

ProRes 422 Proxy is a high-quality, medium data-rate file format for moving images that makes relatively large file sizes in exchange for being very fast to decode. As an added bonus, Apple Silicon-based Macs have hardware which specifically accelerates ProRes decoding, making them an especially good choice.

PhotoJPG and H.264 both make the tradeoff in the opposite direction; they favor smaller file size in exchange for being more intensive to decode. That makes them a good choice for streaming or downloading, but the wrong tradeoff for a situation where the files don’t need to be downloaded, and do need to be played with precise timing.

For still images only, there is no meaningful performance difference between using JPG or PNG for your format. Other still image formats are not recommended.

Best

Sam

—

Sam Kusnetz (he/him) | Figure 53

s...@figure53.com

[micpool]

Hi Sam,

I think you may have misunderstood the point that  Jim was making. He was talking about using a short ProRes .mov file instead of a jpg or png for stills.

On an M1 Mac they do seem to load and play about  10 times faster than a jpg or png. With 50 files preloaded  there is a visible  black state before the image appears after a GO with jpgs or pngs, whereas with ProRes mov files there isn't. In fact with no preloading the .mov files are faster displaying than preloaded jpgs or pngs.

Therefore it is probably true that if speed of loading, or time from GO to display is your primary concern,  the best format for still images is as Jim says,  a short ProRes file with a hold on end.

(Single Frame .mov  files seem to work fine, and even ProRes 4444XQ is faster than a jpg)

MIc

[Sam Kusnetz]

I sure did misunderstand!

Thanks, Mic.

Moving along, nothing to see here…….. :)

Best
Sam

––
Sam Kusnetz [he/him/his] (what is this?)
Figure 53
https://qlab.app | https://figure53.com

--

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/cb4ee7d6-bdbf-4cf1-8475-44337ce4c6d8n%40googlegroups.com.

[fg]

I don't use an M1 on stage, but this is all fascinating. Thanks 

[micpool]

Jim 

You are right about the faster loading speed  for ProRes videos in comparison with still images, both when preloaded or not. 

I have to say though that I can only demonstrate this superiority when using large numbers of simultaneous images and when just using a handful of images per cue, even on a 10 year old computer there is not really much difference in the loading times between jpgs, png or  ProRes .mov files.

Are the still  images you are using, where you have to resort to converting them to ProRes video files the same pixel dimensions as your video version? 

Could it be that something else is changing when you convert the images, and that the container and codec aren't what's causing the slow loading of your stills?

When deciding to use .jpg or .png, I agree with Sam that there is no performance difference, but I think, in general that pngs are preferable because the colours more closely match those of ProRes Video, when used with the default file exports and renders from Adobe apps. YMMV

MIC

[Chris Ashworth]

One other scenario we saw that pushed us to turn auto-load off by default (even though in most scenarios it’s helpful to use it) is workspaces that start off with very large sequences, such as a long slideshow of still images and videos. In prior versions of the program this could cause problems when trying to open a document on older or less capable computers.

One other note that I don’t think I saw yet in the thread is that it is also possible to use Load cues to automate when a tricky sequence gets loaded, separately from using auto-load. This can sometimes be handy to program in loading a sequence that needs it but shouldn’t be auto-loaded for one reason or another.

-C

To view this discussion on the web visit https://groups.google.com/d/msgid/qlab/22ee22e7-d20e-4e33-9bf1-0d58cd17a19cn%40googlegroups.com.

[jimsta...@zoho.com]

Mic et al:

Essentially the images are all different resolutions.

  The most obvious latency with JPGs was in a timeline which only sent to one display, but back when I was running the show on mid-2014 13" MBPs, OS 10.13.6 with 8GB of memory.

At that time there was no additional audio. Currently there are two audio tracks synced with the audio from the main video. (screenshot attached)

  Main video was originally 4x3 (from an old TV show) and therefore custom geometry.

Both of the still images that follow are also custom geometries to fit.

Processing for the video wall has latency, so there's already an AU delay of 250ms on the main video. With JPGs the additional latency was obvious.

  Currently on a 2018 15" MBP OS 10.14.6, 32GB memory, 2 displays: main/backup switched via 2 MIDI master/slave V1-HDs through a single Caldigit TB3 Mini on each MBP, and audio usually DVS.

Jim