<Dynamic> range control sources

[jackmau]

Hi @helgoboss,

I am not sure if this has been asked in the past (I can see this potentially related to #161), and I think this may not be trivial in terms of implementation, but could be (at least for my use cases) a huge time saver.
Whenever mapping certain targets, I find myself easily having hundreds of realearn mappings which tend to be duplicated aside from minor source details (on midi sources channels and CCs, on OSC folders).

I was thinking that it could be cool, using a similar logic to the current <Dynamic> targets, to have some sort of ranged <Dynamic> sources as well. Let me show you what I mean with an example:
Suppose I have 8 faders/knobs which I want to map to the level of 8 tracks. The 8 faders have the same midi CC but on different channel (1-8), or different CC (let's say 50-57) on the same channel. Normally I'd need 8 mappings. It could be cool if I could define a single mapping with MIDI source <Dynamic> with an internal variable representation of x (or a MIDI CC of 50+x in my second example) and then use x as a standard <Dynamic> parameter to calculate the track affected. Naturally I would want to limit the range of x somewhere. This is even more useful with OSC and their message structure which naturally leads to a /x/target structure.

This would, however, brake the 1 mapping = 1 source logic onto which realearn is built, and, I imagine, make certain features like feedback more complex to debug. I am not married to the idea of the 1 mapping = 1 source, but in case you didn't wish to part from that, I would be more than happy with just a sort of wizard that allows me to do something similar and then creates individual mappings.

P.S. I think I may be lonely in ending up using hundreds of mappings even only using limited MIDI sources, mostly because I combine conditional mappings with midi output to be able to write down control data from a realearn instance to playtime, then reassigning the output of playtime to another realearn instance. But I do see the very obvious benefit for any OSC user.

[helgoboss]

@jackmau Not sure if you have seen it but the latest prereleases of ReaLearn offer an API that allows you to generate ReaLearn mappings with Lua: https://forum.cockos.com/showthread.php?t=178015&page=42

Even with dynamic sources, you would sooner or later hit limits. With a real programming language you don't. That's why I consider the API as the new main mechanism for dealing with complex mapping scenarios such as yours. You also don't run into the debugging issues that you mentioned because at the end everything boils down to a list of mappings.

The downside of using the API is that you have to move away from a click&happy GUI approach to writing text. But I feel that with really complex scenarios this is the right way to go. Plus, I have made it easy to start using the API by letting ReaLearn build some initial code snippets for you.

I have been thinking a while about implementing an idea similar to yours: Making it possible to use variables in source virtual control element IDs, e.g. ch{i}/fader and then make it possible to refer to them in dynamic target expressions. Maybe I will still consider that one day, but it has the same downsides.

[vonglan]

@jackmau: I suppose you have already used a good code editor (I use vim) to copy/paste/replace the mapping files?

[jackmau]

@jackmau: I suppose you have already used a good code editor (I use vim) to copy/paste/replace the mapping files?

To be honest I didn't. I have been using the GUI, which is great at testing stage, but cluncky when scaling to a big number of assignments.

@jackmau Not sure if you have seen it but the latest prereleases of ReaLearn offer an API that allows you to generate ReaLearn mappings with Lua: https://forum.cockos.com/showthread.php?t=178015&page=42

Even with dynamic sources, you would sooner or later hit limits. With a real programming language you don't.

I had not seen that, and as usual you manage to get my requests implemented before I actually ask for them. Big Kudos for putting this in, as it looks ideal and perfectly matches my need. Closing this issue as a consequence.

The downside of using the API is that you have to move away from a click&happy GUI approach to writing text. But I feel that with really complex scenarios this is the right way to go.

I may not be the realearn target user, but this is not a downside for me. Your examples are nice even if I have not written any Lua before. By exporting to Lua I can study the assignments and quickly change them. Will test more in the following days, but seems very intuitive and a major time saver.

I have been thinking a while about implementing an idea similar to yours: Making it possible to use variables in source virtual control element IDs, e.g. ch{i}/fader and then make it possible to refer to them in dynamic target expressions. Maybe I will still consider that one day, but it has the same downsides.

With this new API, I don't see that much the need for it. Th only think which may be useful, quoting @helgoboss on Reaper forums is

as the API has stabilized, I plan to make ReaLearn Script a native preset format for ReaLearn. Which means, ReaLearn will offer a possibility to declare a compartment as "Script Compartment" and then will save and load that compartment as Lua code (and adjustments will be possible only by adjusting the code).

This will make Script a bit more neat.