Inconsistent runtimes for chasers
Posted: Thu Apr 04, 2024 12:37 am
I'm trying to build up lighting for a high-school drama production, and have been running into a range of serious problems. The topic of this particular post is the inaccuracy I'm seeing in the real runtime of chasers.
First, we have 3 moving heads, 2 pars, and 2 bar lights, nothing fancy. With the fixtures we have we're going to have to move the lights all over the place, both switching from one location to another, and following actors through scenes. As a musical (Beauty and the Beast), there are a lot of musical numbers that I want to actively lock down to specific times, because the music is already doing that. Others we'll have to step through manually.
I'm using a collection of scenes, some with just the movement channels for individual lights, others with the lighting channels, and then collecting the appropriate combination of scenes into a collection for each lighting cue, then listing those collections as steps in the chaser, with fade and duration set based on the music. (I'm brand new to QLC and this kind of lighting operation, so if that doesn't make sense I'd be happy to learn a better way - I'm going to start researching the Show Manager tonight, now that I've got a better handle on the actual drama cue...)
Here's the problem: for the first part of the prologue I put together a chaser with something like 10 lighting cues (collections of scenes per above) with a runtime of 1min40sec. As I was building the chaser, I kept having to adjust the times of the steps over and over, until I decided to time the entire chase. The first time I ran it I got 1min46sec from my phone's stopwatch. I restarted the program, and another run got closer to 1min41sec. Neither is sufficient, as even the smaller error would rapidly deviate far too much over the course of a 5-8min musical number.
I'm running on a laptop that should have more than enough power (I don't remember off the top of my head but I think it's at least an 8th gen i5), with updated Windows 10 and outputting over an Enttec Open DMX USB (that I've had for ~20 years....), and see no hint at all of strain on the machine, though I haven't looked at CPU load directly. However, I see that the countdown bar in the cue list tends to only get 3-5 "FPS", which seems rather odd considering the system should be running at the default 50Hz refresh. I also see stuttering in the light fades that seems to indicate that the effective DMX output rate might not be what it should.
I've set the enttecopendmxusb registry parameter to 256 as we're only at ~200 channels, with no obvious result. At one point I changed the mastertimer frequency to 100Hz, and the result was that the chaser time got *dramatically* worse, with the countdown clock running something like 1/2 or even 1/3 realtime, so that could be a hint.
I'm going to try to do some more experimentation tonight with a dummy show, but my guess is that the chaser is constantly doing a bunch of relative time delays, which give rise to a multitude of possibilities for unexpected delays caused by things like the Windows scheduler, rather than using absolute timings based on the computer's actual clock.
I need to find a solution to this inaccuracy, as I would very much prefer to be able to run each musical number in the show as a completely self-running chaser. There are going to be a *lot* of cues in this show, and having to do all of them by hand would be extremely error-prone... One potential workaround I can think of is to break the chaser into smaller groups, where a manual forward step triggers a group of 3-5 steps in the chaser that have specific timers attached, and the last one has an infinite duration that "resets" any accumulated timing errors, and hopefully occurs at an obvious and easy-to-hit cue in the production.
Are there any Windows-level optimisations that should be done? Another path forward may be running on a Linux machine with a realtime kernel? I'm a Linux guy anyway...
Thanks!
First, we have 3 moving heads, 2 pars, and 2 bar lights, nothing fancy. With the fixtures we have we're going to have to move the lights all over the place, both switching from one location to another, and following actors through scenes. As a musical (Beauty and the Beast), there are a lot of musical numbers that I want to actively lock down to specific times, because the music is already doing that. Others we'll have to step through manually.
I'm using a collection of scenes, some with just the movement channels for individual lights, others with the lighting channels, and then collecting the appropriate combination of scenes into a collection for each lighting cue, then listing those collections as steps in the chaser, with fade and duration set based on the music. (I'm brand new to QLC and this kind of lighting operation, so if that doesn't make sense I'd be happy to learn a better way - I'm going to start researching the Show Manager tonight, now that I've got a better handle on the actual drama cue...)
Here's the problem: for the first part of the prologue I put together a chaser with something like 10 lighting cues (collections of scenes per above) with a runtime of 1min40sec. As I was building the chaser, I kept having to adjust the times of the steps over and over, until I decided to time the entire chase. The first time I ran it I got 1min46sec from my phone's stopwatch. I restarted the program, and another run got closer to 1min41sec. Neither is sufficient, as even the smaller error would rapidly deviate far too much over the course of a 5-8min musical number.
I'm running on a laptop that should have more than enough power (I don't remember off the top of my head but I think it's at least an 8th gen i5), with updated Windows 10 and outputting over an Enttec Open DMX USB (that I've had for ~20 years....), and see no hint at all of strain on the machine, though I haven't looked at CPU load directly. However, I see that the countdown bar in the cue list tends to only get 3-5 "FPS", which seems rather odd considering the system should be running at the default 50Hz refresh. I also see stuttering in the light fades that seems to indicate that the effective DMX output rate might not be what it should.
I've set the enttecopendmxusb registry parameter to 256 as we're only at ~200 channels, with no obvious result. At one point I changed the mastertimer frequency to 100Hz, and the result was that the chaser time got *dramatically* worse, with the countdown clock running something like 1/2 or even 1/3 realtime, so that could be a hint.
I'm going to try to do some more experimentation tonight with a dummy show, but my guess is that the chaser is constantly doing a bunch of relative time delays, which give rise to a multitude of possibilities for unexpected delays caused by things like the Windows scheduler, rather than using absolute timings based on the computer's actual clock.
I need to find a solution to this inaccuracy, as I would very much prefer to be able to run each musical number in the show as a completely self-running chaser. There are going to be a *lot* of cues in this show, and having to do all of them by hand would be extremely error-prone... One potential workaround I can think of is to break the chaser into smaller groups, where a manual forward step triggers a group of 3-5 steps in the chaser that have specific timers attached, and the last one has an infinite duration that "resets" any accumulated timing errors, and hopefully occurs at an obvious and easy-to-hit cue in the production.
Are there any Windows-level optimisations that should be done? Another path forward may be running on a Linux machine with a realtime kernel? I'm a Linux guy anyway...
Thanks!