Solo frame with chasers reset dmx value to 0
Brought to you by:
mcallegari79
Menu
▾
▴
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
Last edit: Joep Admiraal 2014-12-19
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.
Last edit: dmxWolf 2015-02-10
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.
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.
Nope... Sequences do it too.
Yes just tried it and I can confirm this.
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.
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.
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.
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...
Last edit: dmxWolf 2015-02-13
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. :(
Last edit: dmxWolf 2015-02-13
Ahhh now this explains why I never had problems, because I only stop the sequences after it completed all the fades.
Yep. And if your holds are all set to 0 it'll always reset when stopped, because it's always in a fade. If you don't use fades (in or out) then it won't reset to 0. But then you're snapping to each step.
No what I did without knowing this was turning the speed dial up for the wait times of the steps so remain at a certain step and then I stopped the sequence/ started another.
What I would like to add is that it would be quite useful to have a "choose wether to reset values to 0 or not"-checkbox for each sequence/chaser etc. because in some circumstances I find it quite useful. For example on channels where I have a "focus chase" for moving heads. When the function gets "fixed" and values don't return to 0 some movers will keep the big focus instead of the standard. What to do about this behaviour then? :/
It won't be a problem if chasers get fixed to work the way they should, because when it's stopped all channels used in the chase would revert back to pre-chase values. So your focus would end at the value it was before the chase, be it 0, or any other value. THIS "reset to 0" bug has turned out to be a fade issue, not a chase issue though. It affects all channels used in the fade, whether they're intensity, non-intensity, HTP, or LTP.
Could this be the fade problem?
In scene.cpp
in postRun
Line 631 fc.setFadeTime(overrideFadeOutSpeed());
Line 632 fc.setTarget(0);
Would
fc.setTarget(fc.current(getAttributeValue(Intensity)));
set the ending value to the current value?