Help : Dynamically changing live.remote targets problems
I've been toying with this idea of a "contextual mapper" in M4L.
The basic concept is to store and recall presets of bindings from a single MIDI CC to different parameters in Live. So depending on the context the same controller encoder would control this or that parameter.
basic function under the hood would be :
- get the value, the min and the max of the new grabbed param
- scale the value to the 0-127 for the MIDI controller
- scale the MIDI controller value to the param min/max.
- control the param from the controller.
here's a patch that seem to work on edit mode, but can act weirdly in "normal" mode when the editor is closed.
To test, first map two different params with the store messages. Then you can toggle between the two controls with the toggle box. The dial controls the param.
PROBLEM : if you store two params with different ranges, e.g. a send (0. 1.) and a pan (-1. 1.), and stupidly click several times on the toggle and don't even touch the control dial, you'll see the pan increasing by itself. The problem does not occur in edit mode.
Any idea where the issue could be ?
Wouldn't there be some rounding errors from floats/int infinitesimal stuff not visible on a side but growing fast on another?!
Yeah I suspected that but :
- the first value jump can be quite big
- this doesn't explain why it's working ok in the editor.
I get Error
live.remote~: "normalized" is not a valid attribute argument, in Max 8.5.6.
Is the patch for Live 12?
@double_UG
sorry for this, I'm using L12 indeed. I'll post an updated version asap. I'm not even sure why I used the normalized attribute, but maybe simply removing it works...
Edit : removed the attribute, patch still functional, updating the first post.
Well,
I'm really sorry, I realize that the patch also uses [live.map] so it's not possible to test if you're not using Live 12 beta.
I'll try to make it work on L11 and come back here. Sorry for the bother.
UPDATE :
To understand my issue I've made the simplest patch possible that illustrates it, and also posted a video.
My guts say that the problem comes from the fact that there are timing issues between [sig~] and the switching of targets. Any thoughts ?
https://youtu.be/Ru0XCxVJ3B4
check your order of execution, you set the new value while remote~ is still mapped to prev parameter.
A simple fix would be to reset the remote~ before switching. Generally you could filter the output to remote~ when you are only updating the visual state of your dial.

Thanks !
It does indeed fix the value changing when switching targets...
However, if I save the set while something is mapped, then reloaded, it still loads with the wrong value.
--------------------------------
Thanks double_UG !
I didn't think of just automatically releasing the parameter, that's so simple en brilliant.
(Also tried to remove persistent mapping before, didn't make any difference).
or use live.object with set value, if you don´t need audio rate.
Edit : nevermind, getting tired.