Q Light Controller+

Sounds exciting. Looking forward to testing it. Thanks for your work!

Just commited a prototype on my git repository: https://github.com/mgubisch/qlcplus/
feel free to check out an try
unfortunately you have to build it from source currently, but I don't want to create packages for prototypes
If you need any help let my know


The folliwng is included
- Working Protype with Overwriting working as expeced
- Can be enabled and disabled via Button
- Fix for HTP return to zero Problem in Monitor Mode

Known Issues
- On Override Disable the slider does not fade
- Override Button not accesable via external control
- Unhandled if two Sliders are going to override the same channel

Didn't also take care about cosmtic things like sizes and colors, just the mechanism currently

Hi Baer,
thank you very much for you work. I just tested your version and unfortunately it did not work exactly the way I expect.
Basically I would sum up the things happening in two issues:

1) The monitoring feature only works for upwards adjustment.
Please have a look at the attached workspace. The RGB sliders on the left control RGB scenes. The RGB sliders on the right are our new ones (with monitoring enabled).
Move one slider on the left upwards, the corresponding slider on the right follows this movement (as expected).
Move the slider on the left downwards, and the corresponding slider on the left will not follow this movement (not as expected).

2) When deactivating "OVR", the slider should go back to the value applied by the scenes.
Again, this only occurs if the monitoring slider is above the value of the scene.
So set the scene to say 50, press OVR on the monitoring slider and move it to 100. Press OVR again (deactivate it) and the slider should go back to 50, but it stays at 100.

Hope this is clear enough though. If not, just ask and I'll try to clarify!

Again thanks for your work, this already looks very nice!

Regards,
siegmund

For others that want to try this change: https://ci.appveyor.com/project/mcalleg ... /artifacts contains automated test build for windows.

I was able to try siegmund's test work space on Mac OSX. I managed to build a version from the source, a first for me.

Just to add my findings, the new slider, when monitoring, also overrides the scene if moved upward without the OVR button being pushed. This shouldn't happen.

I am assuming that the new slider type will be able to be selected from the slider properties as an option?

Thanks for the work on this, it is looking promising.

siegmund wrote: 1) The monitoring feature only works for upwards adjustment.
Please have a look at the attached workspace. The RGB sliders on the left control RGB scenes. The RGB sliders on the right are our new ones (with monitoring enabled).
Move one slider on the left upwards, the corresponding slider on the right follows this movement (as expected).
Move the slider on the left downwards, and the corresponding slider on the left will not follow this movement (not as expected).

Thanks for the hint, haven't seen this issue yet, will try your workspace as soon as possible

siegmund wrote: 2) When deactivating "OVR", the slider should go back to the value applied by the scenes.
Again, this only occurs if the monitoring slider is above the value of the scene.
So set the scene to say 50, press OVR on the monitoring slider and move it to 100. Press OVR again (deactivate it) and the slider should go back to 50, but it stays at 100.

This one i know, just forgott to mention on the known issues, should be fixed by end of this week.

mlohrey wrote: Just to add my findings, the new slider, when monitoring, also overrides the scene if moved upward without the OVR button being pushed. This shouldn't happen.

Hmm ok, this is from my point of view normal HTP behaviour, so just as i would expect such a slider to work. Am i totally wrong here?
This is quite different to the old behaviour, because formerly in monitor mode the slider always returned to 0 without a scene or to the scenevalue.
With change of execution order the monitored slider behaves now for HTP mode as one would expect, so upwards you can overwrite your scene value always.
If you set a new scene the slider should be jump to the new scenes value. At least it did in my testcase, hopefully I haven't destroyed something here.
In OVR mode you can control the channel absolutly in both directions.

mlohrey wrote: I am assuming that the new slider type will be able to be selected from the slider properties as an option?

This is not implemented, but should be no big deal do enable/disable this via level mode slider properties

I have one more behavoiur detail to discuss:
If two of the new sliders try to control the same channel, should there be exclusivle one slider to control, or shall we use normal HTP/LTP behaviour for this?
From implementation site i would prefere HTP/LTP behaviour, because this is much easier to implement.

Baer wrote: mlohrey hat geschrieben:
Just to add my findings, the new slider, when monitoring, also overrides the scene if moved upward without the OVR button being pushed. This shouldn't happen.
Hmm ok, this is from my point of view normal HTP behaviour, so just as i would expect such a slider to work. Am i totally wrong here?

I think this is a controversial issue. But I tend to say just leave it as it is, so to have HTP behavior. Because otherwise either the monitoring slider could not be moved away from the current level until OVR is activated or it simply has no effect if moved away from the current level.
Nevertheless we really should discuss this.
@mlohrey Do you have an example where you need the behavior described by you?

Baer wrote:If you set a new scene the slider should be jump to the new scenes value. At least it did in my testcase, hopefully I haven't destroyed something here.

Not always - as mentioned in issue #1 this only works when adjusting upwards.

Baer wrote:I have one more behavoiur detail to discuss:
If two of the new sliders try to control the same channel, should there be exclusivle one slider to control, or shall we use normal HTP/LTP behaviour for this?
From implementation site i would prefere HTP/LTP behaviour, because this is much easier to implement.

I would say use HTP/LTP behavior. Not only from the implementation point of view, but also for less confusion. Because otherwise we need to deactivate OVR on all other overriding sliders, this is probably not what the operator might want.
In addition to that, an overriding slider is not meant to be overridden again...

siegmund wrote:In addition to that, an overriding slider is not meant to be overridden again...

Thats the intended usage yes.
But to prevent this, tell the user that he did something wrong aso is difficult to implement and huge effort.
Without preventing this we need some definied behaviour and there i would suggest normal HTP/LTP for all sliders with active override.

siegmund wrote:Not always - as mentioned in issue #1 this only works when adjusting upwards.

Will check this, in my orignial version where i changed to monitor slider behavoir (without the changes for override) the behaviour was the following:
LTP mode has not changed due to the former implementation
HTP mode: You can only move the slider upwards, if you try to get below the Scene it sticks to scene value. This seems to be correct behaviour.
Because of HTP output value can't be below Scene value, so monitored Slider also can't be below Scene value.
On changing scene slider changed to new Scene value and you can again alter between Scene value and Max value, but not below Scene Value. Thats what the override implementation will be for...

Baer wrote: siegmund hat geschrieben:
In addition to that, an overriding slider is not meant to be overridden again...


Thats the intended usage yes.
But to prevent this, tell the user that he did something wrong aso is difficult to implement and huge effort.
Without preventing this we need some definied behaviour and there i would suggest normal HTP/LTP for all sliders with active override.

I'm completely with you on this.

Baer wrote:HTP mode: You can only move the slider upwards, if you try to get below the Scene it sticks to scene value. This seems to be correct behaviour.
Because of HTP output value can't be below Scene value, so monitored Slider also can't be below Scene value.
On changing scene slider changed to new Scene value and you can again alter between Scene value and Max value, but not below Scene Value. Thats what the override implementation will be for...

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.

Baer wrote:
Hmm ok, this is from my point of view normal HTP behaviour, so just as i would expect such a slider to work. Am i totally wrong here?
This is quite different to the old behaviour, because formerly in monitor mode the slider always returned to 0 without a scene or to the scenevalue.
With change of execution order the monitored slider behaves now for HTP mode as one would expect, so upwards you can overwrite your scene value always.
If you set a new scene the slider should be jump to the new scenes value. At least it did in my testcase, hopefully I haven't destroyed something here.
In OVR mode you can control the channel absolutly in both directions.

No, you are right, I just explained the situation badly.

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.

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.

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

Holidays sound good.

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.

Thank you for your work on this, it is very impressive!

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...

You already deserve your holidays very much, Baer

Hi,

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.

Thanks again to all of you for the work done on this topic!

Good Morning Guys,

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.

Hey Baer,

I'll just try to clear something out:

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

1. shortylight proposed: Automatic activation of override mode when slider is moved away from the current level
2. mlohrey proposed: One need to activate OVR before the level can be overridden
3. 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.

Hope everyone is Ok now with this definition?

Hi Bear,

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?

Again, thank you for your great work!

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.

Thanks for your work, can't wait to test