Q Light Controller+

Hi all,

I have a solo frame with buttons for several chases which control the pan/tilt of the moving heads.
When one chase is running and I press the button of another chase the dmx values of the pan/tilt channels are first set to 0 and then faded to the first scene of the chaser.
This causes the heads to move very fast to their base position every time I switch to another chaser.
Did I configure something wrong?
I'll attach a sample workspace which illustrates the issue.

Thanks,
Joep

Hi,
in my moving heads is the same problem ...

Help anyone?

Please try setting times for the fadeouts, you have currently set them to 0.

I added a fadeout time of 1 second to both chasers.
Now the values are not dropping to 0 instantly but moving from their original value to almost 0 and then moving up to the value of the newly selected chaser. So this is still not what we would expect.

I think going to 0 is build in to reset the values after you click on an active button in the solo frame. In that case it can be useful to have the values reset to 0.

Maybe we should alter the behaviour to only do the reset when no other buttons in the solo frame are selected?

This is a bug or just a wrong implementation of how chases act when stopped. Any time you stop a chase, whether it's in a solo frame or not. It doesn't matter where the chase button is. I've been fighting with this myself, trying to find a workaround to get movements to work right. And it's not just pan and tilt channels. ALL non-intensity LTP channels that have been used in the chase reset to 0 when a chase is stopped. THIS SHOULD NEVER HAPPEN. The correct implementation for a chase (and EFX) is to reset ALL DMX values to what they were when the chase was started.

At the very least, don't reset them to 0, as this really screws things up. This isn't optimal though, because your heads, gobos, etc may not stop in a good position when the chase is stopped in a solo frame with other scenes still running in other frames, but at least you could try to stop it at an acceptable time. This may cause you to miss a cue. (i.e the heads would be pointing in an undesirable direction when the chase is stopped, but at least they wouldn't stop and jerk back to home position or your gobo or color wheel wouldn't fly back to blackout.)

PLEASE PUT THIS ON THE CRITICAL FIX LIST. This one fix will make QLC+ the BEST and most powerful controller out there. But right now it's preventing me from going live with it.

Also, while we're on the subject of chases... If your chase uses a scene that is currently running on a button in another frame, it will completely skip the step with that scene.

If someone can direct me to the code that makes it reset to 0, I'll see if I can fix it.

exactly!

Try to use sequences for movements, these do not reset after stopping.

First, finding what makes it reset is half (or third) of the work. Second, tracing where/why it happens certainly helps designing the fix.

FYI: http://qlcplus.zvukari.sk/doxygen/index.html is pretty current doxygen documentation - if you don't have good IDE, doxygen provides hyperlinked sources.

Now to the point:

All this happens in a separate thread that is started for MasterTimer. ~30 times per second MasterTimer::timerTick() is called. It resets intensity values and relative values, and then calls timerTickFunctions() - for processing functions, timerTickDMXSources() - for processing external Inputs and timerTickFader() for running GenericFader::write() - GenericFader is responsible for fades between values.

This is the basic skeleton. Read through timerTickFunctions() and perhaps also timerTickFader().

The rest is in Function::start(), Function::postRun(), Function::write(), Chaser::write(), Chaser::postRun(), GenericFader, FaderChannel.

I'm pretty sure I tried sequences too and it happens with those as well. Which makes sense, because sequences are controlled in chaserunner.cpp if I remember correctly. I'll try again to confirm.

I'm pretty sure I tried it with sequences and it happens with those as well. Which makes sense, because sequences are controlled in chaserunner.cpp if I remember correctly. I'll try again to confirm.

Thanks Jano! I'll have a look. My programming experience is in Perl, but hopefully I can make sense of it.

Hmmm. My replies aren't posting. I guess SourceForge is still not fixed completely.

Nope... Sequences do it too.

Update... Chases exit properly if set to single shot, UNLESS it is stopped by clicking the button before it completes. Does this give any clues?

Actually I shouldn't say they exit PROPERLY, as they don't revert back to pre-chase values, but they don't reset to 0.

Yes just tried it and I can confirm this.

Aha! New info... It only resets to 0 if the chase is stopped during a fade. If it's stopped during a hold they stay at the current value. So... is it possible to complete the fade immediately (override fade speed to 0), then exit? This would at least stop it from resetting to 0.

Or maybe
stop(timer, universes);
??? I don't really know how this all works yet...

Ugh. This isn't a problem with only chases. It's a problem with all fades. Any fade that's interrupted before it completes will return all active channels to 0. If it's interrupted by starting another scene in the same solo frame they will reset to 0 and the new values from the new scene will NOT take affect. This is a pretty serious problem. I suspect it's in fadechannel.cpp

An EFX doesn't act this way. When it's stopped the values stay at their current values, or change to the values of the new scene that stopped it. Maybe a comparison of how each handle being stopped would reveal the problem and the fix?

I'll post an example workspace tomorrow demonstrating this. Right now I have to get ready for a show. Unfortunately I won't be using QLC+ for it.

Ahhh now this explains why I never had problems, because I only stop the sequences after it completed all the fades.