If a Fader control’s maximum value is greater than 127 and the value set is greater than 63, an incorrect value to format will be provided to the control’s Formatter.
Steps to reproduce
Create a Fader control with Message Type = None, Min Value = 0, Max Value = 128, a Formatter and a Function. In my example, the Formatter is formatUserPresetPos and the Function is updateUserPresetPos.
Try setting various control values, using either the E1 hardware interface or programmatically from Lua.
Expected result
All values are formatted correctly.
Actual result
Values set to greater than 63 are provided to the Formatter as n+1, when n is the set value. Consequently the Formatter will return incorrect text for display. Take these examples from my Lua debug prints:
updateUserPresetPos: Unformatted value is now 63
formatUserPresetPos: Formatting value 63.0 to User 63
updateUserPresetPos: Unformatted value is now 64
formatUserPresetPos: formatting value 65.0 to User 65
Discussion
The value range 0 to 128 is significant. The problem cannot be reproduced with value range 0 to 127. I set Message Type to None rather than CC because the required value range is outside the 0 to 127 bounds.
I used a Fader control because I found that, when I tried a List control I was unable to update the control’s value programmatically from Lua. Perhaps that’s a related problem.
Thanks Thomas! Now I realise what the problem is; and I have a fix.
In my original example
The setter function printed valueObject:getMessage():getValue().
The formatter function printed value and used that in the formatting algorithm.
The problem is that, EDITif the control’s maximum value > 127 then for valueObject:getMessage():getValue() >= 64, value is 1 higher. This is true of both the setter function and the formatter function.
In the attached revised example, the prints demonstrate the problem.
Fader setter parameters: valueObject:getMessage():getValue() = 63; value = 63.0
Fader formatter parameters: valueObject:getMessage():getValue() = 63; value = 63.0
Fader setter parameters: valueObject:getMessage():getValue() = 64; value = 65.0
Fader formatter parameters: valueObject:getMessage():getValue() = 64; value = 65.0
I already knew that valueObject:getMessage():getValue() tends to be more reliable than value. Even so, the demonstrated behaviour does not look right. Is it still a bug?
Either way, I have an easy fix, to use valueObject:getMessage():getValue() instead of value in the formatter function.
I should add that I cannot reproduce the problem for a List control with maximum value = 128.
My original formulation of the bug is incorrect. If it would help, I’d be happy to make a new bug report, or rewrite the opening post of this one (though I can’t change the misleading title). Please let me know what would be best.
Hi, I think there might be a misunderstanding here. The value variable passed to the callback functions is a display value, ie. the value that the user sees on the screen. On contrary, the value queried with the valueObject:getMessage():getValue() is the underlying MIDI value. The controller converts between the display and MIDI values using the information about their minimum and maximum values, type of sign, etc. If the display value range is > 127 while the midi value range stays 0 .. 127, there will be difference between the two. It is an intended behaviour.
Please let me know if the explanation above helps. If not I will try harder
@martin Please try out the bounds.SOR project I attached to a previous post. You do not need to be concerned with the first two controls, which were put there first by Thomas. Concentrate on the Fader control called Simon, which I added.
Sweep the control upwards from its initial zero position, shown by the formatter as “Pick User”. Pause when you get to or just before 63, shown by the formatter as “User 63”. That’s the last value for which there is no problem.
Then carefully turn the knob to show “User 64“. The formatted value is correct, because I applied the fix I’ve learned, to avoid using the value parameter. However, if you look at the debug prints, you will see the problem.
Fader setter parameters: valueObject:getMessage():getValue() = 63; value = 63.0
Fader formatter parameters: valueObject:getMessage():getValue() = 63; value = 63.0
Fader setter parameters: valueObject:getMessage():getValue() = 64; value = 65.0
Fader formatter parameters: valueObject:getMessage():getValue() = 64; value = 65.0
@SimonORorke I followed your instructions, and what I see is still in line with the expected behavior. Your display range is set to 0–128, which gives 129 values. These are mapped to the MIDI range of 0–127, i.e., 128 values. When you turn the knob, Electra proportionally maps every display value to a MIDI value (and vice versa). Since it uses whole numbers (integers), this mapping results in the step you noticed at 64. In other words, the display value must reach 128 at the end, while the MIDI value ends at 127.
If you change the maximum display value from 128 to 127, the display and MIDI values will map 1:1. If you change the maximum display value from 128 to 256, the display value will increase twice as fast as the MIDI value.
@martin Thank you for your clear explanation. Because the names are the same, I had assumed that the VALUE range I defined would map to the value parameter. Now I have a better understanding of how the two function parameters fit into the structure of controls in general. List controls behave differently because explicit mappings are defined between display values and values.
