I run into the following related CC fader bugs (on firmware 2.1.8.a). See the attached preset to reproduce (as a .txt file or else the forum doesn’t get it)
E1 bugs.txt (3.7 KB)
-
Faders getting stuck at value: 7bit MIDI CC faders with ranges mostly negative (eg a range -12…1 with default value -12) or a 14bit fader with range -70…0 with default value get stuck. The 7bit fader can be move with a fast twist, the 14bit fader doesn’t respond.
-
Faders with a value range (not MIDI value range) larger than 0…511 (or transposed variants) do not display their value on the E1; this is also the case if the actual value to display is formatted through a LUA formatting function.
-
Faders only send a value message if their displayed value changes, not if their underlying MIDI value changes. Combined with the fact that you cannot define floating point minimum and maximum values (to display them you need the LUA formatter functions, but these also use the displayed value range as their input), this makes it hard to create fine-grained controls that have a short range (e.g. filters with a -15…15dB range). This can be ‘hacked’ by defining a display range of -150…150 and defining a LUA formatting function that divides by 10 and shows a float), but given the limitation in point 2 above, this limits the usefulness of 14bit faders: they essentially cannot show their value (or else their resolution is crippled).
-
If a fader has a negative minimum and positive maximum display value and a default display value in between, the fader is rendered as a white bar from the default value to the current value. This is great for PAN like faders, but confusing for VOLUME like faders, that typically have a small positive dB range.
-
With every outgoing CC message, the E1 sends a large SysEx message too: F0 00 21 45 7F 00 73 65 6E 64 4D 65 73 73 61 67 65 3A 20 70 6F 72 74 3D 30 2C 20 63 68 61 6E 6E etc.