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

[Baer]

Hey Matthias.

I while back you asked for some button designs. I thought I might give it ago. This is one for the auto-reset.

Logos for Buttons.png

I haven't done this before so didn't know how big they should be or in what format.

Feel free to ignore them completely or if you want me to do some more work on them let me know.

Cheers

Mark

Thank you for the nice icons, maybe we use this if auto reset is enabeld, therefor we would need a differnt one showing that reset only happens on user action.
This would allow to quickly see in which state the fader is.
To achieve this the coloring and/or desing should be different from the current one to make it easyier for the user to differneciate.

Size should be ok (haven't checked the needs yet) but i think we can scale them down to the needs.

[mlohrey]

Some grey versions. These could be the re-set buttons.

Left button is inactive, right would be active.

I like the circular ones without the frame.

[mcallegari]

While developing QLC+ 5, I started to draw some diagrams of how I implemented certain mechanisms in the UI. They help me a lot to understand the efficiency and to avoid forgetting things.
So today I spent some time to create one for you guys, to show what happens in the QLC+ engine every 20ms:
https://docs.google.com/drawings/d/1KGh ... sp=sharing
That is a simplified version of the whole thing, but I think it gives the idea.

As you can see, every time the engine clock ticks, all the intensity channels are reset, and a Universe creation restarts from scratch, passing through stage 1, 2 and 3.
Every stage applies the HTP/LTP rules, unless it is specifically asked to force a DMX channel to a value, ignoring such rules.

One important thing to keep in mind, is that on every stage, the order of execution depends on the ID of a Function/Widget, which is assigned upon creation. Those are fixed and saved into the project XML file, so they won't change in time, to guarantee a certain order and hierarchy.

So, back to this long discussion, if a VC Slider with ID 100 tries to override some channels and then another widget with ID 200 acts on the same channels, the higher ID wins. (always after HTP/LTP rules)
So basically what you're asking is not possible at the moment. At least not without specific constrains.

The exception was already done for the Simple Desk, but that's just a single (and special) so called "DMX source".
Here you're talking about one or many VC Sliders that don't know anything about the other widgets in the Virtual Console, so QLC+ cannot guess which is one is the most important for you.

Please meditate about this topic now that (hopefully) you have all the information, and then we'll see how this can be implemented, possibly without hacks or huge rewrites of how the engine works right now.

[Baer]

Hi all together

First I want to thank Massimo for the great diagram, most of the things i had already figured out (and have drawn a similar diagram but mine was missing some parts), and thought i can handle them.
But the parts i didn't know (like the ID order) may cause some trouble and heavy restrictions.

By the way Massimo I have a question on the behaviour. Just for curiosity, but what is the reason for completly resetting and recreation of all the universes on everey tick? I'm sure there is a reason but I don't get it.

What i currently did to achieve override is to create an array for override values and one for override propertie if the channel should be overwritten. This puts away most of the problems caming from execution order.
With Massimos diagram i figured out the follwing drawbacks and constraints this afternoon.

- Scene Flashing won't affect the overwritten channel (this may be acceptable behaviour because we want to have control, if flashing should be possible well problem.)
- Simple desk sliders (without implementation change) wont be able to controll the overwritten channel (this is one i don't like)
- If two sliders try to control the same channel it depends on creation order of the sliders which will win. I see no possiblity in preventing this with affordable effort, not sure if this is a good idea to let the user take care about because i think this will lead to much confusion
- There is also the known problem from monitoring mode that a slider is only able to handle one level, so what if two channels are assinged and a scene sets them to different levels?
After some tests: Ignoring this is bad because it can lead to the fact that the slider is never ever updating on scene change.

If i missed something (quite sure I did) feel free to add
Not sure what the project owners are thinking, but If this where my project I wouldn't accept a feature with this problems an user confusion.
But from a quick view the effort to make this stable enough for an official release is currently somehow exploding

Therefore direct Question to Massimo and the other main Contributors:
Do you see any possibilty of getting this thing stable enough to be part of an offical release with affordabel effort? If yes I could use some advice/help
Is such a behaviour/use case even desired from your point of view?

Otherwise I won't only implement the things a mentioned in my last post and then stop the development, because for my usecase the current version works as I need it.

[mcallegari]

By the way Massimo I have a question on the behaviour. Just for curiosity, but what is the reason for completly resetting and recreation of all the universes on everey tick? I'm sure there is a reason but I don't get it.

HTP is the reason. In fact LTP channels don't get reset.
Only starting from 0 and going through all the entities contributing to a channel value in a universe you can obtain "the winner" with the highest level.

Do you see any possibilty of getting this thing stable enough to be part of an offical release with affordabel effort? If yes I could use some advice/help

Unfortunately it's not an easy feature to implement. If I had to do it, I could think of some exotic solutions, but none of them really convice me.
Moreover, the ID order is "hidden" to the users, so you would get weird behaviours and couldn't explain why. I need to think some more how this could be implemented.

Is such a behaviour/use case even desired from your point of view?

Seeing the participation to this thread, I understand this is quite a wanted feature so I believe it should be implemented, in the proper way.
On the other hand, and speaking on a more generic level, during the last 4 years I implemented a lot of new major stuff, but I also added a gazillion of new options, especially to VC widget configuration pages. Last but not least: play/pause vs play/stop button in VC Cue List widget.
My fear is that adding and adding and adding more options will end up in a Frankenstein software, which could be appreciated by "power users" like you guys, but might totally confuse newcomers, who might want to choose an easier software.

With QLC+ 5 I want to break this tendency, because in my opinion it is counter-productive. My idea is that QLC+ should be an intuitive software, where you need to read the manual only if you are an advanced user. In any case my feeling is that users don't read the manual anyway...
So the idea is to hide all the "extra options" into some "advanced" section on each component. Idea pretty much taken from Videolan Client, or Kodi if you prefer.
Also, the basic options are the ones covering 90% of the user needs, while advanced options cover just the remaining 10%. So there's no need to confuse 90% of the users for the good of the 10%.

So, please standby and give me some more days to think about it. Probably during xmas holidays I can dedicate some time to come up with a prototype and see if it satisfies your needs

[siegmund]

Thanks for clarification of these things, Massimo! It helped me a bit to understand the difficulty of implementation.

With QLC+ 5 I want to break this tendency, because in my opinion it is counter-productive. My idea is that QLC+ should be an intuitive software, where you need to read the manual only if you are an advanced user. In any case my feeling is that users don't read the manual anyway...

I'm afraid this is the normal way - no user reads the manual until he realizes that it is really necessary. This does not depend on how experienced somebody is with the software, it's just a general problem.
Anyway, I like the way of simplifying the UI for new users!

For now, I just can say keep up the good work and thank you for all your effort!

[Baer]

HTP is the reason. In fact LTP channels don't get reset.
Only starting from 0 and going through all the entities contributing to a channel value in a universe you can obtain "the winner" with the highest level.

Thank your for the explanation, not its clear to me.

My fear is that adding and adding and adding more options will end up in a Frankenstein software, which could be appreciated by "power users" like you guys, but might totally confuse newcomers, who might want to choose an easier software.

I understand that fear, if you want a broad userbase it need to be easy in the first place.
The feature we are discussing here is very usefull for technical applications.
For me a monitoring slider which take control of the channel if i move it and will be resetted on scene/function change directly to scenes value would be totally fine for me

With QLC+ 5 I want to break this tendency, because in my opinion it is counter-productive. My idea is that QLC+ should be an intuitive software, where you need to read the manual only if you are an advanced user. In any case my feeling is that users don't read the manual anyway...
So the idea is to hide all the "extra options" into some "advanced" section on each component. Idea pretty much taken from Videolan Client, or Kodi if you prefer.
Also, the basic options are the ones covering 90% of the user needs, while advanced options cover just the remaining 10%. So there's no need to confuse 90% of the users for the good of the 10%.

I like this idea, keep it going please.

So, please standby and give me some more days to think about it. Probably during xmas holidays I can dedicate some time to come up with a prototype and see if it satisfies your needs

Would be gread, If you need any help let me now

[mcallegari]

Good news. I finally found the time to process this.
For who wants to build from sources, my changes are in the "owrslider" branch on GitHub (https://github.com/mcallegari/qlcplus/tree/owrslider)

Basically the trick has been to add the possibility to a VC Slider in level mode to request a higher priority to the QLC+ engine master timer, but always before Simple Desk, so it's still possible to override channels from SD.
After a VC Slider goes into "override" mode, channels are forced to be LTP, exactly like Simple Desk does. A reset button is visible at the bottom to "disengage" the override, like Simple Desk.

Now, for simplicity I haven't added any new option, so at the moment "monitoring" implicitely means also "override" if the slider is manually moved.
If you need also the possibility to enable/disable overriding at live time, please let me know.
Also, for now there is no visual indication that the override is in place, but I can easily add that once I have the confirmation this is the behaviour you want.

And yes, right now when you reset the override, the slider jumps to the monitoring value. Doing a fade is no easy at all. So for now, let's keep it simple and progress step by step.

Windows build available here (4.10.6.22): https://dl.bintray.com/mcallegari/qlcplus/

[mlohrey]

Thanks Massimo

This is a great step and will be fantastic for live events.

I found one slightly odd behaviour. To test this version, I set up a simple cue list with some basic scenes to see the effect and watched the DMX output at each stage. There are 4 dimmers on 4 channels that are mapped to the 4 sliders.

I then set slider one to 80 and worked my way through the cues. I had assumed that the DMX output for slider one would remain constant but for values in the cue that are above 80, at the beginning of the Cue, the DMX value jumps to the one set in the scene then fades back to 80. I made a movie of this.. https://www.dropbox.com/s/8y5zyxz9u0c4g ... r.mp4?dl=0 (Slider one Controls the two spots stage right)

I would have assumed that once the slider had over-ridden the scene values that it would be an absolute. I also tested the same scenario with simple desk and the behaviour is the same. This is consistent with your explanation of the changes you made.

I also tested the DMX dumping of an altered scene and that works well. There is one small improvement, but I am not sure how possible it is. If you make a change to scene by use of the over ride slider, then dump the values back into the same scene (updating it to the new look) and then click the cross to reset the slider, it returns to the original scene, not newly saved one. If you go to the next cue and then back to the previous one, the saved scene is available. I am guessing this is something to do with how a cue is loaded but it would be great if it could update immediately to scene adjustments.

Thanks for your work on this.

Newslider Test.qxw

(8.2 KiB) Downloaded 464 times

(Tested on Mac OSX)

[mcallegari]

Hi Mark,
thanks for the accurate report.
That makes sense indeed. If you look at my diagram above, VC Sliders in level mode act on stage 2, while Scene fade out (you have 3 seconds each) act on stage 3, so they have a higher priority, even than Simple Desk.
You'll notice also that since the fade out is HTP, the higher you move an "override" slider, the lesser you will see the fade out kicking in.

Unfortunately at the moment there's nothing that I can do about it, unless some bigger action is taken towards stage 3.
For example I could think to merge stage 3 into stage 2, but this would mean fade outs can be easily overridden in a unwanted way. (most likely you can say goodbye to them)
I need to think some more about it.

[mlohrey]

It does make sense in light of your flow diagram.

Perhaps you need a stage 4. This would be a good place for simple desk and then it would become the absolute master.

Thanks for taking the time to consider feature

[mlohrey]

This issue doesn't seem to have been resolved: https://github.com/mcallegari/qlcplus/issues/445

Is this related to the order of processing also?

[shortylight]

Hi,
thank you, Massimo for your great work. To me this feature is working well and I found no further issues but the reported ones.

According to your questions:
I do not need live switching of the override mode and I also do not need an extra switch for this mode beside the monitoring switch.

Concerning the visual indication of the override mode I would like to suggest a horizontal split of the indicating colour into a light upper and a darker lower part. With this the border could be used to indicate the level of the monitoring value all the time. This can help to do the missing automated fade manually, as you will know where to put the slider to before you press the reset button. Maybe this is possible to do in the first step and keeps things simple.

Martin

[siegmund]

Hi Massimo,

great job, this looks really nice.

While testing I was curious what happens when adding another slider in level mode without monitoring enabled. It turns out that the new slider type is not monitoring the changes made by another level-slider (try it in the attached workspace). Don't know if we always talked about scenes but I personally would assume that a monitoring slider has a higher priority than a normal slider.
I discovered I get the behavior I want with some actions beforehand:
0 - raise non-monitoring slider (corresponding monitoring slider won't move - not my expectation)
1 - raise slider in monitoring mode
2 - click it's "X" button
3 - the slider is now following the non-monitoring slider (this would be my expectation)

I don't need live enabling of overriding.
In addition to that, I would request an extra option to switch between two "overriding-modes" (as said in a previous post):

As soon as monitoring is enabled, it is possible to pick from two radio buttons:

• Override the selected channels until the Reset button is pressed
• Stop overriding and fade [jump] to the new value if a new value is applied to the selected channels

What would be perfectly cool is the possibility of using an external input for the "X" button.
If there is a visual indication as shorty proposed, then fading isn't so essential for me.

Concerning the visual indication of the override mode I would like to suggest a horizontal split of the indicating colour into a light upper and a darker lower part. With this the border could be used to indicate the level of the monitoring value all the time. This can help to do the missing automated fade manually, as you will know where to put the slider to before you press the reset button. Maybe this is possible to do in the first step and keeps things simple.

Anyway, thanks for your great work!

[shortylight]

Hi,

just a short addition:

3 - the slider is now following the non-monitoring slider (this would be my expectation)

To be more precise, the monitoring slider is following the non-monitoring slider in HTP mode to the scene's value.

Martin

[mcallegari]

While testing I was curious what happens when adding another slider in level mode without monitoring enabled. It turns out that the new slider type is not monitoring the changes made by another level-slider (try it in the attached workspace). Don't know if we always talked about scenes but I personally would assume that a monitoring slider has a higher priority than a normal slider.
I discovered I get the behavior I want with some actions beforehand:
0 - raise non-monitoring slider (corresponding monitoring slider won't move - not my expectation)
1 - raise slider in monitoring mode
2 - click it's "X" button
3 - the slider is now following the non-monitoring slider (this would be my expectation)

This is totally expected instead for what I explained before. Every slider has an ID assigned upon creation, and every slider doesn't know anything about the other sliders.
When they are created (or loaded from a project) they register themselves as "DMX sources" with a certain order, based on their IDs.
If you check the XML file of your test project, you will see that the non-monitoring slider has an ID higher than the monitoring one.
When you start overriding, the slider acquires the highest possible priority, therefore when you stop overriding, they remain with a priority higher than the non-monitoring sliders. That's why they "start to work".

I could make a simple change so when switching from design to operate mode, every monitoring slider will request a higher priority.

As for a "shadow" level when overriding, that's not trivial, cause a Qt Slider doesn't allow that. You can only change the color of the center bar above and below the handle. Nothing else.
I'll see if there's a way to force some mix of colors.

[shortylight]

Hi Massimo,

if it is not possible to have this indication by colour, maybe you or someone else has another idea for a smart way to do that job instead. I thought of a display with numbers, maybe as an additional widget, but that would increase the work in designing a VC a lot. That is why I did not sugget it.

Thank's for the explanation of the behaviour of the level mode sliders again. I did not get it right the first time, as I understood that by this

Basically the trick has been to add the possibility to a VC Slider in level mode to request a higher priority to the QLC+ engine master timer, but always before Simple Desk, so it's still possible to override channels from SD.

that all monitoring sliders would already have a higher priority (and ID) compared to other level mode sliders.

Martin

[siegmund]

Ah, got it - thank you for the good explanation!
I would expect a consistent behavior, it's a bit mysterious that it is working in another way after some actions that look random to the normal user.
So I'd like to suggest to make this change.

I could make a simple change so when switching from design to operate mode, every monitoring slider will request a higher priority.

You can only change the color of the center bar above and below the handle. Nothing else.

What first came to my mind was to indicate where to move the handle by color. So if the monitoring value equals the overriding one everything is green, but if the overriding value is higher than the monitored one the bar below the handle turns red. Don't know if this is clear enough and I am aware that it's a bit complicated to understand for a normal user of the software but if it is the only possibility we have, we should give it a try.

[mcallegari]

I think I've addressed it all !

I've just committed a change ("owrslider" branch) that:
- gives a visual indication of when the override is in place. Unfortunately I wasn't able to change the slider background to red like in Simple Desk. For now the reset button background changes to red, but I guess that would be enough for you power guys
- immediately request a high priority when the monitoring is activated
- shows an additional level bar on the rightside of the slider main level bar. It's a bit ugly to see, but it's functional

Please test and see if the current solution is good.

Windows build available here (4.10.6.39): https://dl.bintray.com/mcallegari/qlcplus/

[siegmund]

This looks really promising

- gives a visual indication of when the override is in place. Unfortunately I wasn't able to change the slider background to red like in Simple Desk. For now the reset button background changes to red, but I guess that would be enough for you power guys

I like it, for me this should be enough as visual indication.

- immediately request a high priority when the monitoring is activated

If you mean this:

I could make a simple change so when switching from design to operate mode, every monitoring slider will request a higher priority.

I'm sorry but I couldn't see this so far. It just behaves the way I already described with my workspace:

0 - raise non-monitoring slider (corresponding monitoring slider won't move - not my expectation)

- shows an additional level bar on the rightside of the slider main level bar. It's a bit ugly to see, but it's functional

Actually I don't think this is ugly. Indeed I consider this pretty cool and really good work
Just let me add a small inconsistency (I'm certain you worried about but maybe someone else has an idea to solve this): The middle of the handle is apparently connected to the top of the green bar. So in this case the center bar in which the handle is moving and the level bar could not have the same size. I see the point that it looks better if they are at the same height but it's not as much consistent as the other controls are.

Another thing I discovered is that as soon as overriding is taken place and the scene slider is moved again, the green level bar should update, too.

Lastly, do you consider a option of the two overriding options I described?

As soon as monitoring is enabled, it is possible to pick from two radio buttons:

• Override the selected channels until the Reset button is pressed
• Stop overriding and fade [jump] to the new value if a new value is applied to the selected channels