Sometimes, in various hosts or plug-ins there are sets of buttons which are designed to be mapped with ONE CC parameter - usally these are "radio" switches (only one of the set can be on at any given time) and the indication that they are controlled by ONE CC parameter is that upon trying to map them, the host or the plug in requires only one CC mapping. A few examples of such controls-case are the set of buttons that define the synced-to-host time of "simple delay" device in Ableton Live or the "sine-saw-triangle" buttons of μTonic (and this is where I spotted the problem).
The logic behind these mappings is that the available 0 - 127 range of the CC parameter is evenly split to the available buttons - for example if we had 2 buttons, any midi message between 0 - 63 activates the first button and any message between 64 - 127 (of a given CC number) activates the second. What happens though with the messages the host re-sends to the Lemur as feedback-bi-directional communication? Well Im not sure but I guess it sends the center value of the ranges 0 - 63 (for the first button) and 64 - 127 (for the second button). - or it might be sending just the first value of the range, Im not sure.
Now the problem which specifically arose was that for ease of use and bi-directional communication, instead of creating a set of pads with custom midi out I used a fader in a case like above. Given though that the parameters in the plug in are really 3 buttons (3 positions of the fader) I set it to "grid = 3".
This worked as expected and it LOOKED like an elegant solution - with a black backround on the fader and the grid option it really looked like a 3-way switch in Lemur.
BUT, I noticed on the midi activity leds of the host (Ableton Live) that after the initial tweaking of the fader in Lemur, the program had engaged in a weird back-n-forth midi messaging - midi messages were going in and out of Lemur and Ableton ustoppably. The only way to stop them was to cancel the mapping I had done.
What really happened was that the ( "center"?) value of the range selected in the plug in (and which was being sent as feedback back to Lemur) wasnt the exact same "value" that the "grid" was "allowing" the fader to have inside Lemur. So, in Lemur internally, the fader, was resending (after the feedback) its "grid" position (nearest grid-allowed position relative to the feedback received) causing a new midi out and of course causing the host to resend the feedback....engaging in a super-frightening (to my eyes at least lol) endless midi activity.
Of course, this is in no way a bug or smthing - I think we should just call it a mismatch of midi messaging between Lemur and the application. Im not posting this to complain or ask for solution but maybe it will save others from big headaches if their host or plug in starts to crash for no apparent reason.
So, long story short even though a fader with the grid enabled appears tempting to be used in cases like above - beware, in the case of bi-directional communication this problem may arise! The solution is to either switch "grid" off or if you are too picky to see a fader in Lemur representing buttons in your software use custom midi out with a set of radio switches. No bi-directional communication - no problems.
