Allow "Rotate" in controller mappings with virtual targets

[vonglan]

The way it works like I want is:

Controller Mapping
	Mode = Incremental Buttons
	Speed Min = Max = 20
Main Mapping
	Step Size = 1 to 100%
	Rotate

However, when I swap the Controller Device with the incremental button (like a Hardware Synthesizer) for a Controller Device with encoders (like the Twister), I do not want the "Rotate" mechanism in the Main Mapping.
I also would not want it if I had configured both increment and decrement buttons in the Controller.
There may be targets, for which "Rotate" is a useful option. But for an incremental button (if I do not have a decrementing button as well), the "rotate" mechanism belongs to the Controller Mapping.

I think the best way to solve it cleanly would be an additional button Mode "Incremental with Rotation" in the Controller Mapping.

[helgoboss]

Phew, that's not easy. Rotation is not supported for virtual mappings because the target isn't known yet. I don't know yet what's the best way to solve it.

There may be targets, for which "Rotate" is a useful option. But for an incremental button (if I do not have a decrementing button as well), the "rotate" mechanism belongs to the Controller Mapping.

I can see how this is a problem in context of #205 (it is not with general-purpose controller presets).

[vonglan]

Phew, that's not easy. Rotation is not supported for virtual mappings because the target isn't known yet. I don't know yet what's the best way to solve it.

Why is it necessary that the target range is already known? I thought the the "virtual values" (the values passed to the virtual targets) are

• +1 or -1% for encoders (or higher percentages, if the encoders offer this)
• 0 to 100% for knobs
• 0 to 100% also for buttons that are used as incremental buttons

Maybe this requires the same kind of concept change in in the Controller Mapping source handling as for #203 .

Or are you thinking about VST FX parameter targets that only have a discrete number of values (e.g. {"lowpass","highpass","bandpass"}. Of course, this can only work "intuitively" if the number of discrete values is known. A source character "Incremental with Rotation" would not work 1:1 (one button press, one discrete value), except by accident.

On the contrary, here I am thinking about having one button "Filter Enveloper Velocity Sensitivity", and wanting to map that to a "continuous" VST parameter.

[helgoboss]

Phew, that's not easy. Rotation is not supported for virtual mappings because the target isn't known yet. I don't know yet what's the best way to solve it.

Why is it necessary that the target range is already known? I thought the the "virtual values" (the values passed to the virtual targets) are

Not just the target range is important, almost everything about the target. With increments/decrements, the current target value must be known in order to determine the final absolute target value. In order to decide when to rotate, "Target Min/Max" must be known as well. A possible step size is needed to decide about the correct increment. ReaLearn goes to great lengths to get this right with all kinds of targets.

• +1 or -1% for encoders (or higher percentages, if the encoders offer this)

+1 or -1, yes. Not a percentage, just discrete increments.

• 0 to 100% for knobs

Yes.

• 0 to 100% also for buttons that are used as incremental buttons

No, also discrete increments.

But no worries, I have an idea now how to do this.

[vonglan]

Maybe it should be described as "Incremental absolute with rotation". It always needs to start with 0 on the first button press, I think.

[helgoboss]

Why do you need another mode? I was thinking to just provide the "Rotate" checkbox.

The first value will always be the one that the main target currently has.

[vonglan]

Why do you need another mode? I was thinking to just provide the "Rotate" checkbox.

If it is possible without an extra mode, fine.

The first value will always be the one that the main target currently has.

How can the Controller Mapping know the target value? Send +0 (relative) the first time, and then evaluate the feedback?

[helgoboss]

How can the Controller Mapping know the target value? Send +0 (relative) the first time, and then evaluate the feedback?

It doesn't know it and doesn't need to know it. It sends +1. ReaLearn's routing logic will send this information +1 to all main mappings with the appropriate virtual source. They will figure out what to do. E.g. if the current target value is 20%, a +1 is received and the step size is set to 1%, it will set the target to 21%.

[vonglan]

Are you sure this will work?
The requirement (or wish) is:

• Be able to have one shared Main Mapping, that works well for both possible Controller Mapping sources:
• Button, that is defined in the Controller Mapping to increment over the full target range in 5 steps (or 8), and rotate
• Encoder, that should increment/decrement in the standard (comparatively small) step size, and NOT rotate

[helgoboss]

Are you sure this will work?
The requirement (or wish) is:

• Be able to have one shared Main Mapping, that works well for both possible Controller Mapping sources:
• Button, that is defined in the Controller Mapping to increment over the full target range in 5 steps (or 8), and rotate
• Encoder, that should increment/decrement in the standard (comparatively small) step size, and NOT rotate

Yes, what makes you think that not? It's about the "rotate" or "not rotate" being configurable in the controller mapping, right? Yes, that will work the way I have it in mind. I could now try to explain you what I have in mind but then I would have to explain many internals of this software. Unless you are really interested in the inner working, I think it's best if you don't focus on the how and more on the what when outlining the FRs.

The "5 steps (or 8)" thing I didn't fully understand. There's no way for relative virtual controller mappings (either encoder or incremental button) to define how much steps it would need to cover the full target range. But I assume this is something you just added for making the example more vivid and with your particular combination of controller and main mapping it happens to be 5 or 8 steps.

[vonglan]

Unless you are really interested in the inner working, I think it's best if you don't focus on the how and more on the what when outlining the FRs.

I know what you mean. I am somewhat interested, but I do not want to waste your time.

The "5 steps (or 8)" thing I didn't fully understand. There's no way for relative virtual controller mappings (either encoder or incremental button) to define how much steps it would need to cover the full target range. But I assume this is something you just added for making the example more vivid and with your particular combination of controller and main mapping it happens to be 5 or 8 steps.

No, it needs to be a useful value. Usability is best in my opinion if it is between 5 and 8 for the full range. 10 would still be ok. But I do not want to press the button on my device 20 or 40 or 100 times, to move from one end of the range to the other.
(I assume if the incremental button was represented as an absolute virtual controller value, this wouldn't be a problem.)

[helgoboss]

Unless you are really interested in the inner working, I think it's best if you don't focus on the how and more on the what when outlining the FRs.

I know what you mean. I am somewhat interested, but I do not want to waste your time.

No, it's okay. When ReaLearn goes from the virtual controller mapping to the main mapping, it doesn't just pass the control value (e.g. +1) but also other instructions e.g. for overriding certain settings of the main mapping. It does that already to enforce "Send feedback after control" if it's ticked in the virtual mapping. It could do the same with "Rotate". Then the main mapping knows "Okay, even I don't have rotate enabled, someone requests me to do rotation, so I do it."

The "5 steps (or 8)" thing I didn't fully understand. There's no way for relative virtual controller mappings (either encoder or incremental button) to define how much steps it would need to cover the full target range. But I assume this is something you just added for making the example more vivid and with your particular combination of controller and main mapping it happens to be 5 or 8 steps.

No, it needs to be a useful value. Usability is best in my opinion if it is between 5 and 8 for the full range. 10 would still be ok. But I do not want to press the button on my device 20 or 40 or 100 times, to move from one end of the range to the other.
(I assume if the incremental button was represented as an absolute virtual controller value, this wouldn't be a problem.)

Is this an addition to the FR then? The ability to define steps (+20%) instead of increments (+1)? Not just about rotate? Is this for patch editing purposes? Because it will result in parameter jumps. Best open a new issue. This is also not mentioned in the initial description.

[vonglan]

Is this an addition to the FR then? The ability to define steps (+20%) instead of increments (+1)? Not just about rotate? Is this for patch editing purposes? Because it will result in parameter jumps. Best open a new issue. This is also not mentioned in the initial description.

This is all about using the buttons to "simulate" a knob, for patch editing. Jumps are no problem (anyway, this is for parameters like "Cutoff Velocity Sensitivity" and "Pitch Modulation Depth" where one might not even notice the jumps).

If ReaLearn could pass the "rotate" attribute to the Main Mapping like you explained, then I think it should work with the speed and step settings from the table above.

[helgoboss]

If ReaLearn could pass the "rotate" attribute to the Main Mapping like you explained, then I think it should work with the speed and step settings from the table above.

Ah, so you make sure that the main mapping step size is something like 20% (for 5 steps). Exactly, that would work because rotation is always done by the main mapping. Then we don't need the other thing, good.