Default Step Size Max = 100%

[vonglan]

Low Prio

From what I understand so far, this is what a ReaLearn user usually wants

[helgoboss]

You mean the users who don't read the manual and think ReaLearn doesn't support acceleration ;) I usually want things constrained and only let them go loose (raise Max) when I allow them to. It's a more precise, minimalist approach ... probably a matter of taste. So I'm not yet convinced about changing this.

[vonglan]

Yes, exactly. For my taste the default should be what most people want.
But I don't mind either way, now that I know how to set it up.

[helgoboss]

Not sure if that's what most people would want/need. One could also argue that this goes against the principle of least surprise.

Anyway, matter of taste, not worth long discussions. Maybe I will change the default as soon as #159 is there.

[vonglan]

One could also argue that this goes against the principle of least surprise.

When would it be a surprise? When the user sees the value 100 in the mapping GUI? Or when he turns the encoder fast, and the value changes fast? Maybe there is something I don't understand yet.

[helgoboss]

It would be a surprise if they use an encoder without acceleration (the majority) and then change to one with acceleration and see that things react suddenly very differently. Or if you use incremental buttons and change from normal to velocity-sensitive buttons and things get way out of line. Even more likely that case.

[helgoboss]

Then users would come and say "Hey, why is this not opt-in?", "How do I make it change always the same no matter how much I press?" ... and we would have an issue like this one again, just opposite direction. Both views are equally valid I guess.

[vonglan]

I don't have experience with different controllers, only the X-Touch Mini, and it supports acceleration.
It seems strange to me that Controller manufacturers would not support acceleration (I mean sending out higher absolute values than just +/-1. By the way I do not know 100% if that is meant by "acceleration").

I seems a pity if users own a controller that has this feature, and it is not automatically activated for them.

But maybe you are right that pros and cons are of similar weight.

[helgoboss]

But you see the inherent problem, right? If one uses incremental buttons, things would just stop working as expected. Even more an issue with normal non-velocity-sensitive buttons that send 127 on press. The target value would instantly jump to 100% ... now that will lead to frustrating user experiences 😆

So the only way would be to have 2 different defaults, one for encoders and one for incremental buttons. This is already way more difficult UI-wise than just changing a default value because always changing the max step size in response to mode changes is also annoying for the user. Maybe he wants to keep it because he knows what he's doing.

Anyways, in most situations that "different defaults" approach wouldn't work anyway because as soon as you have a virtual source, one can't tell anymore if it's an encoder or button.

Edit: And there are definitely many controllers out there which don't support acceleration. No wonder, this is a feature that I guess also a software could provide, maybe ReaLearn itself in future. Which is another reason to not let the hardware feature ifself let interfere by default.

[vonglan]

But you see the inherent problem, right? If one uses incremental buttons, things would just stop working as expected. Even more an issue with normal non-velocity-sensitive buttons that send 127 on press. The target value would instantly jump to 100% ... now that will lead to frustrating user experiences 😆

So the only way would be to have 2 different defaults, one for encoders and one for incremental buttons. This is already way more difficult UI-wise than just changing a default value because always changing the max step size in response to mode changes is also annoying for the user. Maybe he wants to keep it because he knows what he's doing.

Anyways, in most situations that "different defaults" approach wouldn't work anyway because as soon as you have a virtual source, one can't tell anymore if it's an encoder or button.

Yes, I understand now where the problems with a default max=100% are, thanks.

But I do not understand all the use cases behind the step size and speed settings (especially in combination of Controller and Main Mapping, via virtual targets/sources).
My focus is on: Is the decoupling clear? Is the Controller Mapping able to perform all the operations that the Main Mapping should not care about? And vice versa: can the Main Mapping take care of its mechanisms that are dependent on the target parameter?
I would like to understand this better and think more about this.
As I wrote earlier, maybe I will start a thread in the discussion section.

Edit: And there are definitely many controllers out there which don't support acceleration. No wonder, this is a feature that I guess also a software could provide, maybe ReaLearn itself in future. Which is another reason to not let the hardware feature itself let interfere by default.

I think all the controllers like the X-Touch Mini have a microcontroller in them. So they should be able to count "user turned button X right by 5 clicks in the last time interval" and then send that out as relative +5. And it would be a pity if naive users don't know about that, don't change ReaLearn's default max=1%, and think the controller can only react properly to slow speeds.
But as I said, I also understand your point. Maybe 5% would be a good default? The X-Touch encoders rarely send more than that.

Or does "acceleration" mean: If the user turns the encoder fast, scale this nonlinearly, e.g. with x^2?

[helgoboss]

I think all the controllers like the X-Touch Mini have a microcontroller in them. So they should be able to count "user turned button X right by 5 clicks in the last time interval" and then send that out as relative +5. And it would be a pity if naive users don't know about that, don't change ReaLearn's default max=1%, and think the controller can only react properly to slow speeds.
But as I said, I also understand your point. Maybe 5% would be a good default? The X-Touch encoders rarely send more than that.

Or does "acceleration" mean: If the user turns the encoder fast, scale this nonlinearly, e.g. with x^2?

Mmh, I've not looked at it this way to be honest. I thought about acceleration as something that makes the controller emit exactly as many messages as it would do without, just with higher values. Can you confirm that your controller spits out less messages and "makes up for it" by sending higher increments/decrements? That would indeed be a thing that needs to be fixed in ReaLearn because otherwise with the 1% default, fast turns would result in an overall less amount of target change than a slow turn over the same range - and this is definitely undesired. One could also say it results in a message loss.

[vonglan]

Just checking that with MIDI Logger on the X-Touch Mini encoders.
Fast half-turn: 12 messages, adding up to +38.
Slow half-turn: 12 messages, adding up to +12.

It seems these encoders have 24 physical clicks per turn. And send a CC for every click. But the value depends on the speed. So "acceleration" (for these encoders) really means a kind of non-linear behavior.

[helgoboss]

I just checked with the iCON Platform M+ encoders and jog wheel, with the Arturia MiniLab MKII, the Behringer X-Touch One and the Midi Fighter Twister: All the same behavior. The same number of ticks per turn, just higher numbers. I think then it's safe to say acceleration usually means that non-linear behavior and there's no information loss when not processing the higher increment values.

[helgoboss]

Your suggestion of making 5% the default could be a good compromise. It will not let things go haywire when using 100% incremental button presses but still makes the user aware that velocity/acceleration is possible.

• I'll see how this works in practice with all the above mentioned worries.