Redefine unison function

[emoacht]

The unison function (change brightness in unison) has been a function to sync delta (amount of movement) of multiple sliders while keeping the gap between sliders. This gap is necessary to absorb the difference between monitors. When this function was added in an earlier version of this app, the range function did not exist.

To keep the gap unchanged, this function is designed to conform the deltas of multiple sliders. The algorithm to conform the deltas is the key to this function but it has been the fundamental source of trouble. It tries to prevent a delta from being accumulated while conveying it among sliders and it results in unexpected complexity. In addition, the gap can be easily changed when the movement is sluggish. As long as this function relies on the delta, these issues remain.

On the other hand, after the range function was added, the difference between monitors can be better handled by that function than the gap of unison function.

Therefore, I decided to redefine the behavior of the unison function. In newer version, it syncs the level of slider instead of the delta. This level is calculated from the value and the range of the range function.

• If the range is not limited (0-100), the level matches the value devided by 100.
• If the range is limited like 20-80, the level indicates the rate within this range. Let's say the value is 32, it is transformed into the level 0.2 by following formula: (32 - 20) / (80 - 20) = 0.2

In newer version, all sliders in the group of unison share the same level. If the level of a slider in the group is different from the shared level, it will be forcibly conformed to the shared level when this function is triggered. In such case, the level of focused slider supercedes those of other sliders.

This way, the unison function is greatly simplified and becomes robust. The rigid logic to prevent the accumulation is no longer necessary. The link between sliders no longer needs to be recreated when broken.

[JC-LGMS]

Hello, I have a problem with your modification (4.2.2.0). I have 2 identical monitors, but one is brighter. Before your modification I used to have a little delta between 2 cursors,

now I'm loosing it as soon as I modify the brightness. Can you reconsider your modification please ?

[emoacht]

This new unison function is intended to be used in combination with range function. The formula is: level = (current value - lowest value of range) / (highest value of range - lowest value of range)

Case 1: You have two monitors (monitor A and B). Monitor B is always 7% brighter than A.

In such case, set their ranges like:

• Monitor A: 7-100
• Monitor B: 0-93

Then, unison function will always make the brightness value of monitor A 7% higher than that of B.

Case 2: You use monitor A within the range of 10-50. When monitor A is at 10%, monitor B is 4% brighter. When monitor A is at 50%, monitor B is 8% brighter.

In such case, set their ranges like:

• Monitor A: 10-50
• Monitor B: 6-42

Then, unison function will make the brightness value of monitor A 4% higher when monitor A is 10% and 8% higher when monitor A is at 50%.

As such, you just need to adjust the lowest and the highest values of multiple monitors. I think it is quite intuitive.

[JC-LGMS]

Thank you very much 👍 It is not that intuitive but with your explanation I have activated range function and it is working as you said. It's not totally like the previous way because the range function makes us loose lower brightness on A and/or higher brightness on B. That can be annoying at night, eyes are more sensible with low brightness and with a laptop with not very bright panel.

[powerwolve]

I would like to make the request that you give the users the option to use either style of unison control. While some may prefer the new method, I personally prefer the old method much better. It is overall simpler and while not as thorough maybe as setting the range first then changing the slides in unison, the simpler method worked better for me. Would it be possible to implement this choice in the next update please and thank you?

[emoacht]

@powerwolve I reject your request. As I wrote, old method is unexpecetdly complicated and source of trouble. I mean it was too complicated to ensure the expected behavior.

[powerwolve]

@emoacht well this is your software, and I appreciate all of the hard work you put into it certainly, especially given that it's free so I'll have to respect your decision, but all I can say is it worked well for me previously and can only assume for others as well, and by removing a function that the community liked seems to be counter-productive to the software's intended purpose which is to help people. Thanks for your consideration and time!

[emoacht]

@powerwolve The old method worked most cases but there are many edge cases where it didn't. These edge cases are source of headache for a developer.