Solo frame with chasers reset dmx value to 0
-
dmxWolf
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.
-
IDaninator
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? :/
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? :/
-
dmxWolf
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.
-
dmxWolf
Could this be the fade problem?
In scene.cpp
in postRun
Line 631 fc.setFadeTime(overrideFadeOutSpeed());
Line 632 fc.setTarget(0);
In scene.cpp
in postRun
Line 631 fc.setFadeTime(overrideFadeOutSpeed());
Line 632 fc.setTarget(0);
-
dmxWolf
Would
fc.setTarget(fc.current(getAttributeValue(Intensity)));
set the ending value to the current value?
fc.setTarget(fc.current(getAttributeValue(Intensity)));
set the ending value to the current value?
-
dmxWolf
And would
fc.setTarget(fc.start()); //or something like that
set the end value to the pre-run value?
fc.setTarget(fc.start()); //or something like that
set the end value to the pre-run value?
-
dmxWolf
Ok, it just got weirder. The problem with interrupting fades on scenes has suddenly cleared itself up. Since last night it has been working properly. It may have something to do with if you've been editing scenes and running them without saving, closing and restarting QLC+, but I'm not sure.
However, the problem with chases resetting to 0 if stopped during a fade still remains. This is making my brain hurt. lol
However, the problem with chases resetting to 0 if stopped during a fade still remains. This is making my brain hurt. lol
-
Joep Admiraal
I tried this and now the switch between two functions in a solo frame works as expected. However when no items in the solo frame are selected the channels do not get reset to 0. They stick at the value they have when you deselect the button.
For me this is a good solution.
What are the opinions of others, should we create a pull-request for this?
For me this is a good solution.
What are the opinions of others, should we create a pull-request for this?
-
dmxWolf
Yes, please do a pull request. It's better than resetting to 0, which makes them totally useless.
-
Joep Admiraal
Well the way it now works is still useless for me.
I have a solo frame with several color buttons on it.
Now when I switch from red to blue, I expect the red channels to return to 0 and the blue ones to 255.
This is how the current version of QLC+ works.
So I think we need a way to define the wanted behaviour for stopping a function. Either on the function itself, or on the VC.
I have a solo frame with several color buttons on it.
Now when I switch from red to blue, I expect the red channels to return to 0 and the blue ones to 255.
This is how the current version of QLC+ works.
So I think we need a way to define the wanted behaviour for stopping a function. Either on the function itself, or on the VC.
-
Joep Admiraal
I did some prototyping and now am able to do set the stop action for each scene to one of those values:
- ResetToZero
- ResetToStart
- KeepCurrentValues
Only ResetToStart is not working as expected yet.
fc.start() seems the value from a second ago instead of when the user started the function.
I was looking at adding a correct start value somewhere (in the scene, or the fadeChannel) but I don't know how this should work. What should happen for example when two functions are running and one of them is stopped?
I submitted a pull request which contains ResetToZero and KeepCurrentValues.
I added the selection box to the speed dial window of the scene editor.
What do you guys think of the naming and the location?
- ResetToZero
- ResetToStart
- KeepCurrentValues
Only ResetToStart is not working as expected yet.
fc.start() seems the value from a second ago instead of when the user started the function.
I was looking at adding a correct start value somewhere (in the scene, or the fadeChannel) but I don't know how this should work. What should happen for example when two functions are running and one of them is stopped?
I submitted a pull request which contains ResetToZero and KeepCurrentValues.
I added the selection box to the speed dial window of the scene editor.
What do you guys think of the naming and the location?
-
dmxWolf
Awesome! How about naming them
-Reset (As in reset to 0)
-Release (As in release the channels with previous running values)
-Hold (As in Hold the current values on stop)
Just a thought. Not sure what would be most clear to the average user.
I think fc.start() should mabe grab the values immediately in preRun and hold them in a variable that won't be changed by the running chase... like.. ResetToStart = fc.start()
And then at the end something like
fc.setTarget(ResetToStart);
I know this isn't the correct syntax for C++/Qt/QLC+ but you get what I mean.
Maybe any changes that occur outside the chase, like starting or stopping another function, could change the affected channels in ResetToStart. I don't know if this is possible without some kind of major work, but just a thought.
-Reset (As in reset to 0)
-Release (As in release the channels with previous running values)
-Hold (As in Hold the current values on stop)
Just a thought. Not sure what would be most clear to the average user.
I think fc.start() should mabe grab the values immediately in preRun and hold them in a variable that won't be changed by the running chase... like.. ResetToStart = fc.start()
And then at the end something like
fc.setTarget(ResetToStart);
I know this isn't the correct syntax for C++/Qt/QLC+ but you get what I mean.
Maybe any changes that occur outside the chase, like starting or stopping another function, could change the affected channels in ResetToStart. I don't know if this is possible without some kind of major work, but just a thought.