siegmund wrote:Again, all you said is right and working. What is not working is the monitoring feature itself. As soon as you pull the scene slider downwards, the monitoring slider goes not down with it.

Ok, tested your workspace and saw what you ment, need to debug why this happens.

mlohrey wrote:When in the usual slider monitoring mode, it is not possible to adjust the slider at all. I expected to that to overcome this you would need to push the OVR button This would release the slider from monitoring to being able to override the monitored value up or down.

Ok not sure if i got it but I try to explain how i understood.
What you describe is the old behaviour of the Slider in Monitor Mode. There you weren't able to change the value of the slider at all in HTP mode. Making the whole thing more or less useless.
The this thread and related: viewtopic.php?f=29&t=10384
This behaviour I changed to work as intended for an HTP Mode Level slider, meaning the higher value (regardless of Scene or Slider) wins. This works as I expeced, except for the Bug siegmund already mentioned above.

The new override Feature gives you more flexibility:
As long as override is active the slider has full control regardless of scene change (maybe we can make this optional and disable override on scene change)
If override is disabled again slider should currently simply set back to scene value (here is some bug), and later fade back to scene value (not implemented yet)

Thats what i have implemented so far (except for the fading), and what I mainly extracted from the feature list. Hope I got this right, but for me this would be the behaviour I would assume on such a feature and the one a would use. If here any disagreements let me know.

mlohrey wrote:I think it is important to know when the slider is over riding the scene value up or down and the user should have to choose to override the scene. Or as discussed before, if the slider is moved up or down, it assumes the user has taken control and changes to red to indicate this.

This is all nice tho have you writing here, but worthless if the functionality of the feature is broken. Therefore a won't take care about cosmetics, because you can always see if overwrite mode is active on the checked button. If the feature itself is working as every one intends I will think about such cosmetic things and slight usability improvements.

Plan is to release new version by end of this week before i go on holiday, so that everyone can test for a week and find bugs

I understand your view a little better now. You have looked at the situation from the viewpoint of a normal HTP slider and that the OVR button allows you to choose lower values essentially overriding the HTP requirement.

I have looked at the situation from the view of a slider in monitoring mode and that the OVR button would override the locked slider allowing it to adjust the scene.

This is quite similar to what you have already done, it would just mean that the OVR button needs to be engaged before a level can change.
I have no idea how hard this is to implement but my preference would be to have the OVR button indicate that monitoring had been disabled and that the slider was in control. At a glance I could then tell that a slider had been adjusted.

mlohrey wrote:This is quite similar to what you have already done, it would just mean that the OVR button needs to be engaged before a level can change.
I have no idea how hard this is to implement but my preference would be to have the OVR button indicate that monitoring had been disabled and that the slider was in control. At a glance I could then tell that a slider had been adjusted.

That is a very good point - I did not think about that, yet.
So if the monitoring slider could be raised above the scene level without pressing OVR, it has somehow taken control of the channel. So this should be indicated.
While thinking about this I would more and more go with mlohrey's approach because it is more consistent (especially for new users). HTP can be confusing when using it the first time...

I think this discussion leads into a wrong direction. It is not necessary to have a new behaviour for fader in HTP level mode, I think. If we would change the behaviour the chance to have this branch merged into the main branch of QLC+ would not be verry high for compatibility reason. If we return to our initial idea of a similar behaviour like simple desk fader have and if we see our initial definition of the functioality, there will be no confusing situation for users at all.

We have to do the following changes to the actual implementation:

"OVR" mode has to be activated or deactevated in the fader's preferences and not only enabled. With this, there is no change in the behaviour during operation in run mode of QLC+ which could lead to confusion.

As soon as the fader is used manually there has to be a visual indicator that this fader took control (not implemented yet)

With a reset button instead of an activation switch in the fader's GUI the return to "scene mode" would be initiated and the visual indicater would be reset.

In my opinion This would solve all the things discussed in the last posts without leading to a minor function of the fader.

Bear did a first technical implementation without any respect to GUI or "cosmetic" correctness, but we discussed the usability of this. We should agree on the next steps soon, so Bear can do the rest of the work when he returns from holiday.

Did a little debug Session last night and saw what the problem with the monitoring mode is. If your channel is in HTP mode (which i would prefer for intensity, this is way start fixing this in the first place) due to HTP mode scene never writes to channels if slider value is higher than scene value. therefor monitor can never detect that scene has changed the value.
This is also the problem on override disable.
So I need to handly the whole thing somehow differently.

Current offical implementation is somehow useless because you can't even manipulate a channel which is not part of an active scene if the channel is in HTP mode.

On the other Hand we have the override mode. Here we want have full controll over the channel as long as it is active. (Maybe with automatic reset to szene value if this changes)
On disabling override mode Slider value should fade back to Scenes Original value. If slider has control over the scene this should be indicated.

Plan for functionality of the rewritten level mode:
Slider with monitoring disabled: now change to known behaviour
Slider with active monitoring: LTP no change to known behaviour, HTP will react correctly but resetted on scene change (this change is because I need it)
Slider with override active (indicated throgh button):
- Get full controll of channel
- optional reset to scene value if scene changes
- on deactivting override fade back to scene value over time (can be adjusted in the preferences)
- If more than one slider try to overwrite the same channel normal LTP/HTP is taken into accout depending on the channel settings
- activation of override mode will be done during operation and not in the preferences (because I need this and need to be a little selfish on this point)
As soon as the slider is moved away from the scene value (regardless of mode) there will be a visual indication that the slider currently controls the value.

This is basically what i think is possible within current qlc+ structure and the amount of time i can spend on this, so this is more or less fixed, but we can tweek the details on some point.

Will start today and can hopefully provide a version on friday.
If someone can create a nice icon for the override button (active and inactive) and for the indication that slider has control this would be welcome.

Baer wrote:- activation of override mode will be done during operation and not in the preferences (because I need this and need to be a little selfish on this point)
As soon as the slider is moved away from the scene value (regardless of mode) there will be a visual indication that the slider currently controls the value.

So are you implementing it in the way

shortylight proposed: Automatic activation of override mode when slider is moved away from the current level

mlohrey proposed: One need to activate OVR before the level can be overridden

or the way you currently implemented it: One need to activate OVR to override the scene downwards, upwards adjustment is always possible

Honestly, I would prefer 1 because this is really the way we initially defined it.

Anyway, I love to hear some development is going on so I'm looking forward testing the new things. Thanks for your work, Baer!

Option 3 would be the one I would prefere, but i understand that it's behaviour is somehow confusing.
Because I want to handle channels not controlled by an active scene, meaning upwards needs always be possible.

Therefore I think going with option one with a reset to scene value button, and providing an option If Slider should be reseted on scene changes could be a good comprimise.

to me its perfect. I am looking forward to the next version of your implementation.

By the way ... We initially talked about a way to show the scene value inside of the slider in OVR mode all the time (kind of bar graph or so). Did I understand you right, that this will not be possible, as you cannot get that kind of scene information all the time?

I know that we defined that initalyl, with to former version there was this not always possible.
With the version I currently work on it i think it is possible (without any promise) to show the scene value somehow (at least with a label, i think), in a few hours i think a can give you some more details on this.

Baer wrote:Therefore I think going with option one with a reset to scene value button, and providing an option If Slider should be reseted on scene changes could be a good comprimise.

I'm absolutely okay with it. I assume sliders, which are not controlled by any scene at the moment just do not turn red/indicate control.

Baer wrote:With the version I currently work on it i think it is possible (without any promise) to show the scene value somehow (at least with a label, i think), in a few hours i think a can give you some more details on this.

Although this would still be a really nice feature, we don't really need it at the moment. Maybe face on the core functionality first and then do some visual improvements.