4.11.0 Solo Frame Behavior

The issues found when using the Virtual Console
User avatar
maquelle
Posts: 29
Joined: Mon Apr 13, 2015 8:31 pm
Real Name:

siegmund wrote: Sun Jul 09, 2017 12:24 pm
gmint wrote: Sat Jul 08, 2017 9:26 pm I understand that I could put the Auto button outside of the Solo frame, but I did like the simplicity of the previous arrangement.
If you want to stick with the current layout, you can still place the button outside the frame, but "above" the frame.
I also discover this modification in v4.11 and that's exactly what I do on my project : it works great !
Tubby
Posts: 16
Joined: Fri May 29, 2015 10:06 am
Real Name:

Thanks for persisting with me.

Looks like we disagree on whether "Simple Solo 1" should work like "Simple Solo 2". I don't want to keep wasting your time, so I'll write out my reasoning and hope I convince you, but if not I'll leave it alone. If you want to keep discussing it let me know otherwise I appreciate your time.

Background:
To be clear, I am not saying that the changes to Solo Frames in 4.11 were incorrect, wrong or should be reverted. But I do believe that 4.11 now has some weird behaviour (see quote) where a solo frame has buttons for functions (chasers, collections, scripts) that include other functions in the solo frame, i.e. "Simple Solo 1" from my earlier board.
siegmund wrote: Tue Jul 11, 2017 2:11 pm
Tubby wrote: Tue Jul 11, 2017 3:51 am Particularly, I think pressing "Chaser - Blue/Green" in "Simple Solo 1" should run the corresponding function.
It does, but immediately exits again.

I believe that that "Simple Solo 1" should function the same way as "Simple Solo 2" because:
1) It is consistent. To a User, "Simple Solo 1" and "Simple Solo 2" both have 3 buttons, for 3 separate functions, yet they run differently in 4.11.
2) It is logical and simple. As a User, I want to run only 1 of the 3 separate functions in the solo frame at a time.
3) It is efficient. It allows reusing existing scenes, chasers, collections etc. The workaround requires duplicate/redundant functions, which have to be created and maintained. i.e. creating new scenes "Scene Blue Chaser", "Scene Green Chaser " and using those for "Chaser Blue/Green" works as expected.

If I haven't convinced you yet, I'd like to pose these questions to you (you don't have to answer them)
- Why does a Chaser appear in the VC as the Chaser Function and the Current Steps Function?
- Why should a Chaser not appear in the VC as just the Chaser Function?


Finally, siegmund you said:
siegmund wrote: Tue Jul 11, 2017 2:11 pm
Tubby wrote: Tue Jul 11, 2017 3:51 am Is that an incorrect use of a solo frame?
I would not say incorrect, but this setup is not doing what you want to do with it and this is not the fault of the software, but more a design issue of your vc.
This weird behaviour is present in a VC with just "Simple Solo 1" (1 Frame and 3 buttons). I believe that is the simplest way you could create that VC. Also, I believe in 4.11 there is no way to build a VC where only one of the three functions is running at one time.
siegmund
Posts: 703
Joined: Mon Nov 02, 2015 11:03 am
Location: Germany
Real Name: Lukas

Tubby wrote: Wed Jul 12, 2017 4:56 am 1) It is consistent. To a User, "Simple Solo 1" and "Simple Solo 2" both have 3 buttons, for 3 separate functions, yet they run differently in 4.11.
The major difference is, that in one frame the chaser contains the other 2 functions. This should be clear to the user since he created the vc or gave the operator some brief input on the structure of functions.
Tubby wrote: Wed Jul 12, 2017 4:56 am 2) It is logical and simple. As a User, I want to run only 1 of the 3 separate functions in the solo frame at a time.
So here we finally agree :D The point is: A chaser is a sequence of other functions. As soon as you start it, you have a running chaser (which is a function itself) and a running function, which is the one currently "selected" by the chaser. [EDIT:] Simply wrong. See this thread for correct explanation So you somehow propose to stop activating the button corresponding to the currently running function in the chaser as I get from your statement:
Tubby wrote: Wed Jul 12, 2017 4:56 am - Why does a Chaser appear in the VC as the Chaser Function and the Current Steps Function?
If we do that, this will be no more consistent, because the function is running, but the button is not activated. So visually it would look like there is only one function running in the frame, but technically there is the chaser and the current chaser function running.
Last edited by siegmund on Mon Jul 17, 2017 10:40 am, edited 3 times in total.
volmar
Posts: 19
Joined: Sun Jan 03, 2016 4:34 pm
Real Name: Daniele

I'm sorry to disagree with you siegmund.

Not talking about the new behaviour broke my project on many parts... But the solo frame had a logical and useful behaviour, managing scene and chaser togheter.

Take the example of a dimmer RGB fixture.

Like someone said if i select a chaser with different colors I expect every scene colors to deactivate. Which doesn't happen if I put the chaser button outside the solo frame (outputting white because colors start to sum).

Even worse now I can't manage the dimmer channel with the submaster slide. First I could put in one solo frame the dim255 scene button, the submaster slide and the strobo chasers (which contain dim0/dim255 scenes). Now one should create 2 solo frame with 2 submaster sliders making it usable only mapping the sliders with one physical slider (hoping that the MIDI plungin doesn't malfunction).

I see that for a software developer now it makes more sense, but for a lightoperator is a pain. Using QLC+ in the new solo frame I see no pros, only cons.
siegmund
Posts: 703
Joined: Mon Nov 02, 2015 11:03 am
Location: Germany
Real Name: Lukas

volmar wrote: Wed Jul 12, 2017 11:07 am Like someone said if i select a chaser with different colors I expect every scene colors to deactivate. Which doesn't happen if I put the chaser button outside the solo frame (outputting white because colors start to sum).
Since this sounds weird, can you please provide a workspace sample for it?
volmar wrote: Wed Jul 12, 2017 11:07 am Even worse now I can't manage the dimmer channel with the submaster slide. First I could put in one solo frame the dim255 scene button, the submaster slide and the strobo chasers (which contain dim0/dim255 scenes). Now one should create 2 solo frame with 2 submaster sliders making it usable only mapping the sliders with one physical slider (hoping that the MIDI plungin doesn't malfunction).
Why limit (submaster) the dimmer channels and the chaser? This makes no sense, only limiting the dimmer channels should be enough.
gmint
Posts: 114
Joined: Wed Apr 15, 2015 8:04 pm
Real Name: George Qualley IV

I didn't realize I was opening such a can of worms with my original post, but given some of the additional discussion I do feel compelled to comment.
Tubby wrote: Tue Jul 11, 2017 3:51 am 1) When the "Solo" button rules are applied. Should it be just when a "users clicks a button" (old behaviour I think) or when "any button changes state" (new behaviour).
I think this is actually a very good description of the change and I think it's a good description of the paradigm. Personally, I think there was something to be said for the previous behavior and, while I can work around the new behavior (and I can see some possible upsides, e.g. let's say I have my aforementioned "auto" button but I want to temporarily trigger a scene at a specific time, in the past this would have disabled the auto function but now it will continue to run even after I have triggered my temporary scene) it does seem that it might actually impose more limits than I had previously thought. Also, it's clearly breaking VC functionality that's been around for a long time. Also, I do want to point out that, strictly speaking, if we're talking about the "solo" convention as it pertains to an audio console, it actually doesn't violate that convention to have more than one thing active at a time. Again while I understand (and love) the solo functionality in QLC+, on an audio mixing console "solo" has really come to mean "mute everything except for those channels where solo is activated" as opposed to "only allow one single channel to be active."

I'm not sure any of that is really helpful to this discussion, but I guess it's just some food for thought...
volmar
Posts: 19
Joined: Sun Jan 03, 2016 4:34 pm
Real Name: Daniele

siegmund wrote: Wed Jul 12, 2017 12:02 pm
volmar wrote: Wed Jul 12, 2017 11:07 am Like someone said if i select a chaser with different colors I expect every scene colors to deactivate. Which doesn't happen if I put the chaser button outside the solo frame (outputting white because colors start to sum).
Since this sounds weird, can you please provide a workspace sample for it?
Of course, it's attached to this post.
I usually use multiple colour chasers in a workspace, all in a solo frame to keep only one active. Of course if I take them all out the solo frame they don't deactivate when I start another one and then they sum up.
siegmund wrote: Wed Jul 12, 2017 12:02 pm
volmar wrote: Wed Jul 12, 2017 11:07 am Even worse now I can't manage the dimmer channel with the submaster slide. First I could put in one solo frame the dim255 scene button, the submaster slide and the strobo chasers (which contain dim0/dim255 scenes). Now one should create 2 solo frame with 2 submaster sliders making it usable only mapping the sliders with one physical slider (hoping that the MIDI plungin doesn't malfunction).
Why limit (submaster) the dimmer channels and the chaser? This makes no sense, only limiting the dimmer channels should be enough.
To me it seems not. If I take out the solo frame the strobo chaser button the intensity is influenced by the initial value of the submaster slide, but not to later variations. (this case is also in the attached workspace)
Until 4.10 I keep all in a solo frame (dim255 button, strobo button, submaster slide) and it worked.
test.qxw
(10.46 KiB) Downloaded 62 times
siegmund
Posts: 703
Joined: Mon Nov 02, 2015 11:03 am
Location: Germany
Real Name: Lukas

volmar wrote: Wed Jul 12, 2017 6:32 pm Of course, it's attached to this post.
I usually use multiple colour chasers in a workspace, all in a solo frame to keep only one active. Of course if I take them all out the solo frame they don't deactivate when I start another one and then they sum up.
Can you please state what exactly is wrong in this workspace? I can see nothing odd here.
volmar wrote: Wed Jul 12, 2017 6:32 pm To me it seems not. If I take out the solo frame the strobo chaser button the intensity is influenced by the initial value of the submaster slide, but not to later variations. (this case is also in the attached workspace)
This is definitely a bug, I will open a separate thread for submission.
User avatar
mcallegari
Posts: 4446
Joined: Sun Apr 12, 2015 9:09 am
Location: Italy
Real Name: Massimo Callegari
Contact:

Alright guys, let's try to reach a conclusion of this discussion.

What 4.11.0 proposes, is what is written in the documentation since the beginning:
A Solo Frame is almost exactly the same kind of a container as a normal Frame in that can hold various widgets and other frames inside. However, the difference with Solo Frame is that it treats any Buttons inside it differently by allowing only one button to be enabled at a time.
If over the years, users designed their VC taking advantage essentially of a bug, I need to know if it is more important to have solo frames that are not solo frames, or if they should really implement the documented exclusive behavior.

For me the change is trivial (one single line of code) but I need to know what you really want and if the current behavior is so penalizing that it becomes impossible to cover some usages as before.

In any case I'm 100% sure you won't get a QLC+ that reads your mind, especially referring to some "bug" report in the latest test.qxw (with related explanation)

If it might help, I can create a poll, where everybody can vote. I will then revert or keep it as it is depending on the poll verdict.
User avatar
mcallegari
Posts: 4446
Joined: Sun Apr 12, 2015 9:09 am
Location: Italy
Real Name: Massimo Callegari
Contact:

Poll created, please vote.
viewtopic.php?f=17&t=11326

As I'm aware I haven't actually proposed a solution to this, I've had a rough thought of what might make everybody happy, while keeping the exclusive behavior.

Basically the confusion comes from the fact that there is no distinction between a button running a function and a button monitoring a running function. When a button border becomes green, it always seems the button is in a state where it is actually controlling the function. (which in not always true)
So, the idea I've had is to distinguish the two cases with a different visual indication.
For example
- when you explicitly push a button, the border becomes green, as it is now
- when a button "senses" its function is running, the border can become orange (or whatever color you prefer)

When in "monitoring" state, you can still press the button and run its function, so the border will become green and the Solo frame exclusive behavior will be applied.

i'm not sure if this might create even more confusion or if this would be the way to go. In any case I have no idea of the effort it requires and the implications of such change. It's definitely not trivial.
What do you think ?
siegmund
Posts: 703
Joined: Mon Nov 02, 2015 11:03 am
Location: Germany
Real Name: Lukas

I somehow like this idea. It will visually separate the two states and tells the user what is actually going on.
Just a quick first thought, that came to my mind: Maybe this could not be done with a frame, but rather with some highlighting of the font in the button?
User avatar
mcallegari
Posts: 4446
Joined: Sun Apr 12, 2015 9:09 am
Location: Italy
Real Name: Massimo Callegari
Contact:

I have prepared a prototype of the concept mentioned before.
Now buttons show a different visual feedback when they are running a function (green border) or when they are just monitoring a function (orange border)

Note that this doesn't include the 4.11.0 behavior, but it can be easily added. For now I just want to know if it could be a satisfactory solution for everyone.

Test builds with this change:
Windows: 4.11.1.51
macOS: QLC+_4.11.1-TEST-20170715.dmg (this build also reverts to Qt 5.6.2, so it should work on older macOS version too)
Linux: build the "tristate" branch from sources
User avatar
maquelle
Posts: 29
Joined: Mon Apr 13, 2015 8:31 pm
Real Name:

I quickly test this version and it's really great !

Thanks Massimo
volmar
Posts: 19
Joined: Sun Jan 03, 2016 4:34 pm
Real Name: Daniele

mcallegari wrote: Sat Jul 15, 2017 4:15 pm I have prepared a prototype of the concept mentioned before.
Now buttons show a different visual feedback when they are running a function (green border) or when they are just monitoring a function (orange border)

Note that this doesn't include the 4.11.0 behavior, but it can be easily added. For now I just want to know if it could be a satisfactory solution for everyone.

Test builds with this change:
Windows: 4.11.1.51
macOS: QLC+_4.11.1-TEST-20170715.dmg (this build also reverts to Qt 5.6.2, so it should work on older macOS version too)
Linux: build the "tristate" branch from sources
I really think this is a great idea. Thanks for the effort regardless it makes to an official release or not.
siegmund
Posts: 703
Joined: Mon Nov 02, 2015 11:03 am
Location: Germany
Real Name: Lukas

Just tested this and looks nice so far, thank you! I'm sure this will reduce confusion of the users. Before merging, there should still be some testing done. Because as we already discussed in the bug report thread, I think the "monitoring" buttons should not be affected by anything in the same frame, which is not the case at the moment.
Tubby
Posts: 16
Joined: Fri May 29, 2015 10:06 am
Real Name:

Hi Massimo,

Thanks for looking into this. As one of the users that exploited the bug... sorry.

For what it is worth, I do think the 4.11 Solo Frame is good, it enables a way of designing that wasn't possible before due to the bug. Also I think monitoring is a great idea, but I don't think that it will help here.

I think the useful bits of the bug can be reinstated and improved by:
1. Keeping the 4.11 Solo Behaviour.
2. Adding an option to Solo frames to "treat composite functions (see below) as a single function".
3. Add a new VC widget called a "Multi Press Button".
A "Multi Press Button" allows a user to press 1 or more VC buttons at the same time.
Unlike a collection, a "Multi Press Button" follows the VC programing, things like Solo Frames and Submasters. The "Multi Press Button" itself would not latch, but the buttons it presses would react as if the user activated them (don't toggle if already activated).

Expanding on Point 2:
As I see it there are two classes of functions in QLC+: Simple Functions and Composite Functions. I would define these types as below:
Simple Function:
A function that is fully defined and contained within itself.
These include: Scenes, Sequences, RGBMatrix, EFX

Composite Function:
A function that relies on one or more other functions for its definition.
These include: Chasers, Collections, Scripts, Shows (4.11 changes make this a moot point as they have their own private sequences)

As I wrote in earlier posts, I think that composite functions should be able to be treated as a single running function for the purposes of a Solo Frame.
siegmund
Posts: 703
Joined: Mon Nov 02, 2015 11:03 am
Location: Germany
Real Name: Lukas

Tubby wrote: Mon Jul 17, 2017 4:17 am 2. Adding an option to Solo frames to "treat composite functions (see below) as a single function".
Let me first state, that I most probably explained the principle of composed functions wrong to you. Read this thread for a correct explanation by Massimo (so actually, composite functions are already treated as single functions, not as I explained as several functions). Anyway, adding such an option would require a huge change in QLC+ code so I'm sure this is out of the question.
Tubby wrote: Mon Jul 17, 2017 4:17 am 3. Add a new VC widget called a "Multi Press Button".
You can already achieve that with the help of the loopback plugin.
gmint
Posts: 114
Joined: Wed Apr 15, 2015 8:04 pm
Real Name: George Qualley IV

mcallegari wrote: Sat Jul 15, 2017 4:15 pm I have prepared a prototype of the concept mentioned before.
Now buttons show a different visual feedback when they are running a function (green border) or when they are just monitoring a function (orange border)

Note that this doesn't include the 4.11.0 behavior, but it can be easily added. For now I just want to know if it could be a satisfactory solution for everyone.

Test builds with this change:
Windows: 4.11.1.51
macOS: QLC+_4.11.1-TEST-20170715.dmg (this build also reverts to Qt 5.6.2, so it should work on older macOS version too)
Linux: build the "tristate" branch from sources
Massimo, I like the test version. I want to say that when people started to discuss this, I KNEW someone was going to say, "can't we just have it both ways?" :mrgreen: I didn't want to be that guy. But I like what you've done!
User avatar
mcallegari
Posts: 4446
Joined: Sun Apr 12, 2015 9:09 am
Location: Italy
Real Name: Massimo Callegari
Contact:

So, 4.11.0 behavior is winning.
Basically the "monitoring" feature just brings some more clarity to who is controlling who.
Please help me testing version 4.11.1.57 (WIndows) and then I'll merge the change upstream and produce new test builds also for macOS.
Thanks
Pioneer1
Posts: 1
Joined: Tue Dec 20, 2016 11:38 am
Real Name:

Dear Massimo,
First of all, thank you for your great work!

About this discussion,
In version 4.11.0, I have feedback for the TAP on MIDI controller.
(On MIDI controller LED lights up simultaneously to the TAP trigger)
The same way for audio trigger.
This can be done because two buttons with same function can have two different external inputs - one for turning on, the other for MIDI LED.

But in 4.11.1 this doesn't work, because the button in "monitoring" mode don`t send command to MIDI controller.
Any ideas how to do this in 4.11.1 ?
Attachments
TAP_FeedBack.qxw
(6.6 KiB) Downloaded 65 times
Post Reply