Page 1 of 1

dynamic MIDI channel Mapping

Posted: 08 Oct 2014 16:09
by Phil999
in the Lemur editor, MIDI Mapping panel, it would be good to be able to put a variable (expression) into the channel field. That would enable users to change the MIDI channel dynamically.

This is already possible with a MIDI receive script and a MIDI send script, and setting the Target to 'none', bypassing the MIDI Mapping. Still it would be easier to do this inside the MIDI Mapping panel. Especially if you have 100+ parameters.

Re: dynamic MIDI channel Mapping

Posted: 08 Oct 2014 16:15
by Softcore
It is also possible with custom midi out.....but again you still lose bi-directional control.

Re: dynamic MIDI channel Mapping

Posted: 08 Oct 2014 20:14
by nick_liine
You can obtain bi-directional MIDI, but for each Custom MIDI you will have to create an On MIDI script.

Re: dynamic MIDI channel Mapping

Posted: 09 Oct 2014 07:08
by Softcore
Yes Nick correct.....but thats not the full story sadly.

The way objects in Lemur and mapped parameters interact when custom MIDI and OnMIDI scripts work results in erratic behavior of the objects inside Lemur. The OnMIDI scripted feedback, arriving slightly "later" (due to accumulated latency from the "trip" Lemur -> mapped software -> Lemur) from the actual movement of the object makes the object in Lemur "wiggle" or "jiggle" (not sure how I would describe this in English).
This means, the "designer" of such a thing has to incorporate some sort of "delayed" feedback (wait till the object has been "untouched" by the user). At one point, I remember designing the OnMIDI script (for the feedback) to only work when "z" of the targeted Lemur object is 0 to avoid such wiggling.
It all results in one big pile of workarounds IMHO.

Example: Lets say we move a fader with the speed of 1 midi value/ 8 msec (quite fast)
Lets say the accumulated latency is around 16 msec.
Lets say our starting position of the fader is 64 (in midi) and we move it to higher values.
After 16 msec of movement the fader object in Lemur has gone to 66.
Due to the latency the feedback that arrives back to Lemur is 8 msec behind, therefore it is 65.
This causes the Lemur fader form 66 to go to 65 while you are still moving it to 67.

Granted, some software feature a "control surface refresh rate" setting which might help with this problem -Ableton Live specifically, does NOT send midi feedback unless the controlled-mapped parameter has stopped receiving messages but not all software have this function.