Sliders in VC should be able to act like Simple Desk sliders, i.e. overriding the current cue level

Request a feature that you would like to see in QLC+.
Explain in details why you would need it and which is your usage case.
siegmund
Posts: 703
Joined: Mon Nov 02, 2015 11:03 am
Location: Germany
Real Name: Lukas

mlohrey wrote:My recommendation would be to have a slider that monitors the output of the channel and then if the operator chooses to adjust that level the slider turns red, as in done in the simple desk, and then has a button that clears the change and returns the channel to the level specified by the running cue. (I guess a fade could be incorporated here)
In this case we need to determine: Where does this fade come from? How long should we fade? This is very complicated and not really intuitive.
My suggestion would be to have either a button to deactivate as in the simple desk and the value jumps back (not my favorite, because I don't like jumps) or just fade from the overriding value to the value of the next scene as soon as the next scene is applied.

So let's get a bit more precise.

The request is about a new form of a slider. This slider could look like this:
slider.png
slider.png (3.71 KiB) Viewed 54582 times
Normally the slider acts as a level slider with the "Monitor the selected channels and update the slider level"-option is enabled. If you press the button "override active" it gets another color and the highest priority for the selected channels and overrides every other value sent by scenes or something.

In the sliders' properties there can be two options:
[ ] Override the selected channels as long as the "override active" button is activated
[ ] Stop overriding and fade to the new value if a new scene is applied to the selected channels
--> These two options should be exclusive

This should cover all use cases we discussed before.

Maybe one of the developers could comment, how complicated this is to implement, what further details are needed or what problems could arise, which we are not aware of at the moment.
mlohrey
Posts: 243
Joined: Mon Apr 20, 2015 5:07 am
Real Name: Mark Lohrey

May I add an idea or two? ;-)

Sorry for my poor drawing ability

I imagined the slider behaviour would be very much like simple desk. If the slider is moved from the monitored value it would turn red to indicate that it has taken control. Also, it would be useful to have a visual representation of the original cue level in the slider. (this would be handy in simple desk as well). It would mean that it would be possible to manually return the slider to the old cue value before releasing it and avoid jumps. I don't like them either.

If it isn't too hard to program, a property of the slider might be fade time so that if the slider is released returning to the monitored value would be predicable. Sometimes you want a level to persist across several cues so triggering a change when a cue step is triggered would be undesirable.

Lastly, in my slider three, if there was an option to update (tick) the value to the active scene then clicking it would save the level and release the slider and the scene is now updated.

I thought that perhaps a different type of frame (analogous to solo frames... sort of) might be an easy way to differentiate this slider type from the usual one. I coloured my blue for this effect.

Slider one: Shows the slider monitoring the current level
Slider two: Slider is raised and overrides the current level (this could be down as well)
Slider three: Tick button is clicked and level saved to an active scene as determined by the cue list and slider returns to monitoring the cue level.
slider_mark.png
slider_mark.png (6.25 KiB) Viewed 54565 times
siegmund
Posts: 703
Joined: Mon Nov 02, 2015 11:03 am
Location: Germany
Real Name: Lukas

Very good ideas - I really love the "monitoring" part!
mlohrey wrote:Sometimes you want a level to persist across several cues so triggering a change when a cue step is triggered would be undesirable.
Indeed, sometimes you want to have this behavior. But also sometimes you want to have the next scene in control. Have a look at the following example:

Scene 1:
R: 255
G: 255
B: 0

Scene 2:
R: 0
G: 0
B: 255

If you adjust the value of R in scene 1 to 200, this would lead to have the output of (200,0,255) instead of (0,0,255) after scene 2 is triggered.
So my suggestion would be to offer the ability to choose in which way the slider should behave in its properties.

With the other things, I completely agree with you!
Baer
Posts: 96
Joined: Fri Jan 15, 2016 8:40 am
Real Name: Matthias

Would be a real nice feature would love to have it.

Can someone summarize the complete idea.
All intendend behaviours
Which slider modes should be affected (i guess only level mode)?

I think i have some freetime over the next two weeks, so with a concrete summary what to implement i can see if i can come up with some prototype.

To clarify: I'm not an official developer of qlcplus, i can implement but there is no guarantee that this will be included in any official release.
siegmund
Posts: 703
Joined: Mon Nov 02, 2015 11:03 am
Location: Germany
Real Name: Lukas

Hey Matthias,

thank you for your offer!

I'll try to summarize:

We desire for a new type of slider. Normally, this slider should behave exactly like a slider in level mode with the "Monitor the selected channels and update the slider level"-option enabled. Maybe we could make sliders, which have this option enabled, by default behave the way we desire, but we should check beforehand if this breaks backwards compatibility!

About the slider's appearance, please have a look at mlohrey's inspiring post:
mlohrey wrote:I imagined the slider behaviour would be very much like simple desk. If the slider is moved from the monitored value it would turn red to indicate that it has taken control. Also, it would be useful to have a visual representation of the original cue level in the slider. (this would be handy in simple desk as well). It would mean that it would be possible to manually return the slider to the old cue value before releasing it and avoid jumps. I don't like them either.

If it isn't too hard to program, a property of the slider might be fade time so that if the slider is released returning to the monitored value would be predicable. Sometimes you want a level to persist across several cues so triggering a change when a cue step is triggered would be undesirable.

Lastly, in my slider three, if there was an option to update (tick) the value to the active scene then clicking it would save the level and release the slider and the scene is now updated.
mlohrey wrote:Slider one: Shows the slider monitoring the current level
Slider two: Slider is raised and overrides the current level (this could be down as well)
Slider three: Tick button is clicked and level saved to an active scene as determined by the cue list and slider returns to monitoring the cue level. [This should be discussed before implementing]
png by mlohrey
png by mlohrey
slider_mark.png (6.25 KiB) Viewed 54540 times
So this leads to the following functional requirements:
  • As soon as the slider is moved, it turns red and takes absolute control (highest priority) over the selected channels
  • In the sliders' properties there are two options:
    • [ ] Override the selected channels until the "x" knob is pressed
    • [ ] Stop overriding and fade to the new value if a new scene is applied to the selected channels
    --> These two options should be exclusive
  • The sliders stays active (red & in full control of the selected channels), until:
    • If option 1 is enabled in the properties: Active until the "x" knob is pressed
    • If option 2 is enabled in the properties: Active until another scene is applied, which changes one of the selected channels
    --> After this, the slider is no more red and has no more the highest priority, so the channels' value turns back to the scene which is specifying them
The following I consider optional, but really nice to have:
  • The middle of the slider shows the currently monitored value
  • In the properties, there is an option to specify a fade time, which is applied after the slider loses control. A bonus would be to connect this to the speed dial widget, so one can apply this to a speed dial widget and control the fade time with it (this could be really hard to implement but would be very nice feature)
What I think is really problematic and should be discussed:
  • There is an "✓" Symbol at the bottom of the slider, which writes the actual value of the slider to the active scene.
    --> The problem here is to determine, which scene we should write to. Often, there are different scenes active, and also different scenes which have an impact at the selected channels. A possible solution could be a popup-dialog to choose a scene to write to, if there is more than one scene active.
So if I forgot anything, please add it or let me know if I got some of your ideas wrong or you don't agree.

@Bear: If you want me something to test, please let me know!
shortylight
Posts: 31
Joined: Sat Nov 21, 2015 7:06 pm
Location: Münster / Germany
Real Name: Martin Kurze

Hi,

thank you for the summary, it seems to be complete.

I see problems with the "save to szene" feature, too. To make this work properly, you not only have to determine which scenes are affected, but also to see if the scene as a whole is dimmed or not. This could lead to a lot of work. Maybe it is easier just to save that new situation as DMX dump to a new szene if needed ?

There is one additional thing I would like to mention, but probably everyone is aware of it. All faders, button and knobs should be controllable remotely by extrnal devices. The BCF 2000 would be an interesting device for controlling such a fader!

@Bear: I could offer testing, too.

Regards Martin
mlohrey
Posts: 243
Joined: Mon Apr 20, 2015 5:07 am
Real Name: Mark Lohrey

Thanks for making the summary, it looks very accurate.

I agree that saving to a scene is problematic. The DMX dump option seems viable.

I did some testing today, experimenting with dumping the DMX of the adjusted scene into the running scene and it works quite well. Obviously at this stage you can only make adjustments to higher values.

In the current arrangement, it takes too long to do this for a live scenario. The current processes requires

1. Click to select "Dump DMX values to a Function" (some options such as Dump selected channels and dump only non-zero values persist from previous selections)
2. Click to select "Select a function to over write'
3. Click to select "Running functions"
4. Select the function you wish to use. Sometimes a click or two depending on your folder structure
5. Click OK

An option, to quickly over write a scene with the adjusted scene would be great. A single button to get you point 2/3 above. Once the scene was over written, the adjusted slider could return from red to its original colour as scene will be updated.

I also wondered whether simple desk adjusted values might also be dumped as this would allow you to dump a lower channel value. It works quite well for an increase in a channel value. The live scene remains exactly the same once you have dumped the scene and removed the simple desk change. However, for lower values, if you reset simple desk after dumping the values, the scene changes to the original. I thought perhaps the scene didn't over write correctly but if you reload the scene you can see that change was made.
Baer
Posts: 96
Joined: Fri Jan 15, 2016 8:40 am
Real Name: Matthias

Thank you all for the summaries.

For the prototype i thought giving the slider an additional mode with this behavior would be the best way not to disturb the current behaviour.
Also for the first version i would like to postpone the save option (or implement it in a way that only one scene can be active), because determining from two or more sceens seems to be very error prone.

I have one more question regarding your term highest priority.
Should we take GrandMaster and Submaster into account on this slider or not?
siegmund
Posts: 703
Joined: Mon Nov 02, 2015 11:03 am
Location: Germany
Real Name: Lukas

shortylight wrote:There is one additional thing I would like to mention, but probably everyone is aware of it. All faders, button and knobs should be controllable remotely by extrnal devices. The BCF 2000 would be an interesting device for controlling such a fader!
This should definitely be the case, but is ensured by defining only a new slider type - so you could still set an external input for the slider in the general tab of the properties.
mlohrey wrote:An option, to quickly over write a scene with the adjusted scene would be great. A single button to get you point 2/3 above.
I agree - some sort of "shortcut" should be easier to implement
Baer wrote:Should we take GrandMaster and Submaster into account on this slider or not?
IMO definitely yes! We just want to adjust the specific channel(s) in a live situation, this should take Sub-/Grandmasters into account.
Baer
Posts: 96
Joined: Fri Jan 15, 2016 8:40 am
Real Name: Matthias

Good news regarding our feature.

I did some implementations today and came up with some kind of prototype.

Overriding the Channels value itself works perfect, but enable and disable is currently hardcoded in source code.
Hopefull i can make the overridemode switchable tomorrow, then i will push it on my git repo for everyone hows interested to test it.
mlohrey
Posts: 243
Joined: Mon Apr 20, 2015 5:07 am
Real Name: Mark Lohrey

Sounds exciting. Looking forward to testing it. Thanks for your work!
Baer
Posts: 96
Joined: Fri Jan 15, 2016 8:40 am
Real Name: Matthias

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
siegmund
Posts: 703
Joined: Mon Nov 02, 2015 11:03 am
Location: Germany
Real Name: Lukas

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
Attachments
OVR test.qxw
(6.44 KiB) Downloaded 471 times
janosvitok
Posts: 1266
Joined: Mon Apr 13, 2015 7:05 am
Location: Bratislava, Slovakia
Real Name: Jano Svitok
Contact:

For others that want to try this change: https://ci.appveyor.com/project/mcalleg ... /artifacts contains automated test build for windows.
mlohrey
Posts: 243
Joined: Mon Apr 20, 2015 5:07 am
Real Name: Mark Lohrey

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

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.
Baer
Posts: 96
Joined: Fri Jan 15, 2016 8:40 am
Real Name: Matthias

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.
siegmund
Posts: 703
Joined: Mon Nov 02, 2015 11:03 am
Location: Germany
Real Name: Lukas

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...
Baer
Posts: 96
Joined: Fri Jan 15, 2016 8:40 am
Real Name: Matthias

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...
siegmund
Posts: 703
Joined: Mon Nov 02, 2015 11:03 am
Location: Germany
Real Name: Lukas

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.
mlohrey
Posts: 243
Joined: Mon Apr 20, 2015 5:07 am
Real Name: Mark Lohrey

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