Improve source character guessing for iCON controller

[helgoboss]

User reported that a fader is detected as relative encoder type 3 by ReaLearn (whereas it should be detected as "range element"). Reason is that iCON sends duplicate messages when moving the fader:

0: B0 29 00 [CC41 LSB] chan 1 val 0
1: B0 29 00 [CC41 LSB] chan 1 val 0
2: B0 29 01 [CC41 LSB] chan 1 val 1
3: B0 29 01 [CC41 LSB] chan 1 val 1
4: B0 29 01 [CC41 LSB] chan 1 val 1
5: B0 29 01 [CC41 LSB] chan 1 val 1
6: B0 29 01 [CC41 LSB] chan 1 val 1
7: B0 29 02 [CC41 LSB] chan 1 val 2
8: B0 29 02 [CC41 LSB] chan 1 val 2
9: B0 29 02 [CC41 LSB] chan 1 val 2
10: B0 29 02 [CC41 LSB] chan 1 val 2
11: B0 29 02 [CC41 LSB] chan 1 val 2
12: B0 29 03 [CC41 LSB] chan 1 val 3
13: B0 29 03 [CC41 LSB] chan 1 val 3
14: B0 29 03 [CC41 LSB] chan 1 val 3
15: B0 29 04 [CC41 LSB] chan 1 val 4
16: B0 29 04 [CC41 LSB] chan 1 val 4
17: B0 29 04 [CC41 LSB] chan 1 val 4
18: B0 29 04 [CC41 LSB] chan 1 val 4
19: B0 29 05 [CC41 LSB] chan 1 val 5
20: B0 29 05 [CC41 LSB] chan 1 val 5
21: B0 29 05 [CC41 LSB] chan 1 val 5
22: B0 29 05 [CC41 LSB] chan 1 val 5
23: B0 29 06 [CC41 LSB] chan 1 val 6
24: B0 29 06 [CC41 LSB] chan 1 val 6
25: B0 29 06 [CC41 LSB] chan 1 val 6
26: B0 29 06 [CC41 LSB] chan 1 val 6
27: B0 29 07 [CC41 LSB] chan 1 val 7
28: B0 29 07 [CC41 LSB] chan 1 val 7

Duplicate messages look very much like relative messages and therefore ReaLearn guesses they are relative. But we could probably look a bit closer.

[DLongoni]

If that's of any help I had the same issue with knobs on behringer x touch compact. Sometimes they are detected as range, sometimes as button, sometimes as type 3 or type 1 as well. For instance with the following messages the knob got detected as type 1.

17: B0 3F 7F [CC63 LSB] chan 1 val 127
18: B0 3F 7F [CC63 LSB] chan 1 val 127
19: B0 3F 7F [CC63 LSB] chan 1 val 127
20: B0 3F 7F [CC63 LSB] chan 1 val 127
21: B0 3F 7F [CC63 LSB] chan 1 val 127

In fact I didnt look at it but it is an endless knob and I was turning clockwise even though it was at maximum value.

Personally I think this is not the end of the world... One can just go back and check mappings.

[helgoboss]

@DLongoni Is that endless knob configured to transmit relative messages or absolute ones? I mean, what would be the correct detection result in your case?

[DLongoni]

The knob is configured to send CC values from 0 to 127. If turned clockwise the value is increased, unless it is already at 100%(showed by led ring around the knob itself). If the knob it's already at 100% and I turn it clockwise, value 127 is sent. The same is true for 0% and turning it counter clockwise. In that case the value is 0 of course.

The correct result of the detection would be ranged element. But I'm not sure about how you could detect it... So this is the what currently happens in my case.

Knob already at 100%, turn it clockwise, 127 is sent multiple times -> Type 1 detected
Knob already at 0%, turn it counter clockwise, 0 is sent multiple times -> Type 3 detected
Knob turned of just 1 "time" (the knob turning is discretized in this hardware) -> Button detected
Knob turned more than 1 "time" -> Ranged element detected

I don't know if it's possible to do much better than what you already did, though, for detection... You may also want to leave it as it is and let the user be careful about this.

[helgoboss]

I assume you confused the first two lines and it should be instead as below (that's how it's supposed to be if I look at the code). Now let's look at it in detail. For reference: In these comments is written what the different relative types mean.

You have an endless encoder which is configured to transmit absolute values (BTW, which is a bit of a pity :)). Therefore, the desired result is to detect it as range element.

1. Knob already at 100%, turn it clockwise, 127 is sent multiple times -> Type 1 detected
   • I think in this case the algorithm can be fixed by relying on the fact that the user is supposed to always turn clockwise if possible (with an endless encoder that's always possible).
   • It's clear that this can not be "Type 1" because for "Type 1" a 127 means decrement.
   • It's also very unlikely that it is one of the other relative types because 127 only occurs with extreme acceleration.
   • It's also not a button because there are multiple of the same values in one row.
2. Knob already at 0%, turn it counter clockwise, 0 is sent multiple times -> Type 3 detected
   • Even if turning counter-clockwise is discouraged, this can be fixed.
   • It's clear that this is very unlikely to be any relative type because with "Type 1" and "Type 3", zero means "no change at all" and for "Type 2" it should only occur with extreme acceleration.
   • It's also not a button because there are multiple of the same values in one row.
3. Knob turned of just 1 "time" (the knob turning is discretized in this hardware) -> Button detected
   • This obviously can't be fixed because there's just one element to look at.
4. Knob turned more than 1 "time" -> Ranged element detected
   • This is the correct result, so it doesn't need to be fixed.

The other user's case is that multiple of the same values are transmitted in a row and it's wrongly detected as a relative type. This can be fixed in some cases:

• If it contains a zero, it's not a relative type.
• If it's not in the range of the following typical, not extreme, increment relative type values, it should be detected as absolute:
  • 1 to 7 (type 1 and 3)
  • 65 to 71 (type 2)

[DLongoni]

So

1. Sorry, you're right, I confused the first two lines in my previous post. I'll edit it right now.
2. Agree with everything except point 3. for which I'd suggest to check the values. Normally a button sends 0/127. If the values are like 65 68 then it's unlikely to be a button. Again, not the most important thing on earth but since you're doing everything as accurate as possible I'm just suggesting this.

Finally, even if it's a bit OT.. Why would you recommend relative encoders? I'm kinda happy with the absolute functioning right now, especially cause I wouldn't know how to have a visual feedback for relative ones with the led rings outside encoders.

Cheers

[helgoboss]

Thanks for your input.

About 2: I guess it depends on whether one would count velocity-sensitive keys or pads (e.g. on Launchpad 2) as buttons or range elements. Both is valid and I think there's no clear favorite there. However, so far I have detected them as buttons. They can transmit everything between 0 and 127.

I would in most cases recommend relative encoders because:

1. They work without annoying parameter jumps.
   • There are ways to prevent parameter jumps in absolute mode as well, but they can never be as effective as relative ones.
2. You can influence the step size (resolution/speed).

Feedback works no matter if you choose absolute or relative. It's always absolute.

[DLongoni]

Oh well, touch sensitive buttons with aftertouch could pose a real problem for detection indeed... Well, I wouldn't spend too much time on this really... It really could be left to the user...

Mmmm maybe I could give a try to relative settings then.. It would be quite interesting to discuss but I don't wanna spam this issue with OT. Maybe I'll post on the reaper forum after some testing. Thanks again!

[helgoboss]

I mean normal NOTE ON/OFF messages, not aftertouch. Aftertouch should be correctly detected as range element. NOTE ON/OFF is interpreted as button right now, but that's intended.

I want to pay some attention to detail here because ReaLearn is all about, well, learning :) It doesn't take much time, infact this is one of the easiest things. Everything UI related takes a lot of time.