Thanks for this, it’s helpful in terms of demonstrating a brilliant concept of reading values from the faders to dynamically change and update matrix UI. I learned a fair bit from it.
But it does not really solve the problem, so I am not sure if you understand what I meant?
Assume this scenario:
While using Project configuration midi mapping:
1. Midi-to-fader mapping is configured to “reach to change”
2. A track fader is on volume = 5 (range 0-100)
3. A midi knob is on value 90
4. When you touch/move the midi knob, the fader won’t abruptly jump to a value of 91, but you’ll have to move the knob down, to ‘catch’ the value of the fader, and only then it changes the volume – that’s the magic of “reach to change”.
While using macro scripting:
1. A track fader is on volume = 5 (range 0-100)
2. A midi knob is on value 90
3. When you touch/move the midi knob, the fader value abruptly jumps to 91, because “TrackVolume” function does not honor or allow for using “reach to change” option. A volume jump is a small problem in a performance setting 😉
And yes, I know I could try to write another routine in macro to emulate ‘reach to change’ behavior, but that’s producing plenty of unnecessary code, especially that I have a few dozens of knobs. More logical is to have this behavior implemented in “TrackVolume” and similar functions.
Is this still unclear?