General, switchable „Make relative“ for fader/knob Sources

[vonglan]

As user of a MIDI controller with faders or knobs, I would like to be able to switch easily between the default „absolute“ and a „relative“ mode, which simulates endless encoders.
It should be a general switch, so I do not have to duplicate all my mappings.

Background: Many Hardware synths have this feature, e.g. Dave Smith / Sequential (Pot Mode relative).

Limitation: Depending on the fader position and the parameter value, it will not be possible to reach all values on one side (min or max) at first. For small changes, or for the „better“ side, it works great, and avoids the parameter jumps of absolute mode.

Possible implementation (I think):
The switch should be connected to a ReaLearn parameter, and affect all fader/knob Sources of one ReaLearn instance.
There should be a new configuration possibility in the header:
„Relative mode for knobs/faders, switchable on/off with parameter“ and a selection box for the parameter (with default “).
(I am not 100% sure whether this should be for „Controller Mapping“ compartment only.)

[helgoboss]

Sounds good. To be consequent with regard to the current design, the option "Make absolute" should be made available as a mapping-specific setting at first (there's a "Make relative" checkbox already). The second step would be to somehow make this (and not just this) overridable for the complete ReaLearn instance, controllable by a parameter, see #204 comments, #160 and #161.

[vonglan]

here is code that I used in a JSFX script for the purpose:

l_new_cc_abs_val = msg3;
current_mode != c_mode_normal ? (
  a_old_cc_abs_value[msg2] == -1 ?    // initial value
    a_old_cc_abs_value[msg2] = l_new_cc_abs_val;
  l_delta = l_new_cc_abs_val - a_old_cc_abs_value[msg2];
  msg3 = 64 + l_delta;                                // u-he: encoder64
  msg3 > 127 ? msg3 = 127;
  msg3 < 0   ? msg3 = 0;
);
a_old_cc_abs_value[msg2] = l_new_cc_abs_val;

[helgoboss]

@vonglan I was wondering if #12 is an alternative to this ("Parallel" or "Catch up" takeover mode)? (to be released in an hour or so in 2.8.0-pre3)

[vonglan]

I will have a look. (Hopefully I find out this time how to install the beta - by the way I am on OSX.)
Sounds like "parallel" is the same mechanics that I wanted.

Would be nice to also have "It should be a general switch, so I do not have to duplicate all my mappings.".

[vonglan]

If I accept duplicate mappings for the time being, how could I make it switchable? Using two ReaLearn instances (one with relative, one with absolute behavior), and then switching between them with either #109 or (workaround) writing two Lua scripts that do that.
Correct?

[helgoboss]

If I accept duplicate mappings for the time being, how could I make it switchable? Using two ReaLearn instances (one with relative, one with absolute behavior),

That would be possible. However, why do you want it switchable in the first place? If the "Takeover mode" is clever enough to figure out when and how to avoid jumps, why put this extra mental burden on you having to switch to an "Absolute to relative" mode? I'm sure there's some good reason (if Dave Smith synths implement that even in hardware!) I would just like to know about it.

and then switching between them with either #109 or (workaround) writing two Lua scripts that do that.

Maybe, haven't thought about that.

[vonglan]

... However, why do you want it switchable in the first place? If the "Takeover mode" is clever enough to figure out when and how to avoid jumps, why put this extra mental burden on you having to switch to an "Absolute to relative" mode? I'm sure there's some good reason (if Dave Smith synths implement that even in hardware!) I would just like to know about it.

Dave Smith implements both modes in his (current) synths (and a third one, "Passthru", which I assume works as "pickup" in ReaLearn). They are switchable as global parameters. And I often wish they would be switchable with an explicit button.
I think both have their use:

• relative is good when you are trying out presets (because you don't get jumps)
• absolute is better when you create a preset from scratch, because you know what value you want to dial in, so you just change the knob to the physical (absolute) position. And you don't have the disadvantages of relative mode (not being able to access one end of the range directly, until you have turned from min to max and back).

[vonglan]

I just noticed that the parallel takeover mode is at the moment only available for Main Mappings.
For the use case "Hardware synthesizer with knobs (not encoders), map to virtual targets" it would be needed in Controller Mappings.

[helgoboss]

... However, why do you want it switchable in the first place? If the "Takeover mode" is clever enough to figure out when and how to avoid jumps, why put this extra mental burden on you having to switch to an "Absolute to relative" mode? I'm sure there's some good reason (if Dave Smith synths implement that even in hardware!) I would just like to know about it.

Dave Smith implements both modes in his (current) synths (and a third one, "Passthru", which I assume works as "pickup" in ReaLearn). They are switchable as global parameters. And I often wish they would be switchable with an explicit button.
I think both have their use:

• relative is good when you are trying out presets (because you don't get jumps)
• absolute is better when you create a preset from scratch, because you know what value you want to dial in, so you just change the knob to the physical (absolute) position. And you don't have the disadvantages of relative mode (not being able to access one end of the range directly, until you have turned from min to max and back).

Okay, got it.

I just noticed that the parallel takeover mode is at the moment only available for Main Mappings.
For the use case "Hardware synthesizer with knobs (not encoders), map to virtual targets" it would be needed in Controller Mappings.

This is not possible / doesn't really make sense if you think about it a bit deeper. We are talking about mappings with virtual targets. Virtual targets don't have any current value and don't have any particular information available that would let one make an educated decision about the value of "Jump Max". They are non-concrete because all kinds of targets can potentially be connected to it, also multiple ones at the same time.

The solution is to make all jump settings on "Main mapping" side. They belong there. If that main preset is going to be used with a controller that provides encoders (instead of knobs), the jump settings will just be ignored.

[vonglan]

I just noticed that the parallel takeover mode is at the moment only available for Main Mappings.
For the use case "Hardware synthesizer with knobs (not encoders), map to virtual targets" it would be needed in Controller Mappings.

This is not possible / doesn't really make sense if you think about it a bit deeper. We are talking about mappings with virtual targets. Virtual targets don't have any current value and don't have any particular information available that would let one make an educated decision about the value of "Jump Max". They are non-concrete because all kinds of targets can potentially be connected to it, also multiple ones at the same time.

The simple „make relative“ that I would like (and I think has high value) is possible with the 10 lines of code that I copied higher up in the discussion. It does not need to know target values.
In my opinion it makes a lot of sense to encapsulate this absolute/relative translation in the Controller Mapping. I think it belongs there. If you have a global switch between relative and absolute for a Controller, that switch belongs to the Controller, not the target FX.

[helgoboss]

Okay, then it definitely needs to be something else in addition to the current takeover modes. Because takeover modes need to know the current target value in order to detect jumps.

[vonglan]

How this could look in the GUI:
Controller Mapping / Individual Mapping / Tuning / For knobs/faders and buttons:
new Mode "Normal/switchable relative"
which does not need the Control Transformation field, but a selection like for group activation:
Make Relative when modifier on/off --> Modifier = Parameter

(and the JSFX code above has been tested)

[helgoboss]

@vonglan How about offering the mode "Normal - make relative" + a fourth mode <Dynamic>. The dynamic mode would reveal a small text field next to it which allows you to enter an expression (just like the <Dynamic> selectors in the target section). The result of this expression is the index of the mode. E.g. 0 = Normal, 1 = Incremental buttons, ..., 3 = Normal - make relative. This would be in line with the rest of the GUI and more flexible because you can depend on multiple parameter values and you could switch between other modes as well. Your modifier-based use case could be written as p1 > 0 && 3 (using parameter p1 as an example).

[vonglan]

Sounds good. I am not sure whether the full flexibility will be used, but I would be very happy if a switchable "make relative" is possible!

Does it make sense to think ahead to the "zoom" request (#204 ) and how that could be implemented? It is lower priority for me, but it is somewhat similar.

[vonglan]

Two thoughts about implementation of this mechanism:

• The "relative" steps that are sent need to add up to 100%. So the smallest "speed" needs to be 1/127 (or in general, 1/source max).
• So this needs an "override step settings" mechanism, as is also required for Maybe add the possibility for virtual control mappings to send continuous increments #315

Being able to override the Step Size Max setting of the main mapping from the controller mapping. (Similarly to rotate).

[helgoboss]

Two thoughts about implementation of this mechanism:

• The "relative" steps that are sent need to add up to 100%. So the smallest "speed" needs to be 1/127 (or in general, 1/source max).
• So this needs an "override step settings" mechanism, as is also required for Maybe add the possibility for virtual control mappings to send continuous increments #315

Being able to override the Step Size Max setting of the main mapping from the controller mapping. (Similarly to rotate).

This is not really an implementation detail but a requirement. And I think this requirement is nothing else than #315. If #315 is implemented, you would be able to set a step size in the virtual controller mapping and it would travel all the way to the target.

[vonglan]

Yes, the first bullet point is part of the requirement for this issue.

Just to avoid misunderstanding: #203 is more than just #315 .

[helgoboss]

To sum it up: This issue only makes sense to you if #315 is implemented as well. This issue is just #203 (comment), nothing more.

[geoffroymontel]

Would be super nice to use with my Sequential OB6 !

[helgoboss]

Ok, because something similar was requested in #457, here's the thing: Adding a "Normal - Make relative" absolute mode is something that I could implement in no time, very easy. It's just all the requested extras which scared me away from this FR so far (general switch between "Normal" and "Normal - Make relative", step size override, ...). So if there's anyone out there who would benefit of "Normal - Make relative" itself - without the extras - let me know.

[vonglan]

Hi Benjamin, let's drop the bit about switchability.

However, the "relative" steps that are sent need to add up to 100% (100% movement of the controller : 100% movement of the target - if the start is at min or max of both).

Could this be implemented similar to #457, where - technically - an absolute target value is sent?

Should I open a new, separate issue for this simpler request?

[helgoboss]

Would be good, yes. Could you post some examples in this new issue? The 100% movement scenario is good to know but it's also not very interesting because if it would be just that, #457 would be exactly the same. E.g. what happens if the mod wheel initially is at 0% and the target at 50%? What if the 100% of the target is reached? And so on. Just some values are enough to get the idea. E.g. like this:

Initial: source at 0%, target at 50%

1% => 51%
2% => 52%

[vonglan]

#468 opened.

[vonglan]

Now that #468 is implemented, this can be closed.
Switching between absolute and relative can be achieved by activating/deactivating a pair of ReaLearn instances with different Controller Mappings. (Not sure whether having "load controller mapping" as a target would be generally useful.)

[vonglan]

(Not sure whether having "load controller mapping" as a target would be generally useful.)

Another thought about this:
That would also be solved if you offer the possibility to load and save the mappings of an instance as Lua, from a ReaScript (I think you called the ReaScript API). In parallel, it would be nice to load and save presets with that ReaScript API.

[vonglan]

Implemented with #468 .

For the record, I implemented switching now with groups with modifiers.