"Debouncing" faders and encoders

I use information from my faders and encoders to point to the track for parameters I want to change and to switch what's being displayed on my Ableton Live screen. For example, if I move the volume fader for track 1, then Live will display the clip view for that track. Also, movements of my delay and reverb effects faders will be directed to the delay in track 1. If I move the volume fader for track 2, the clip view in track 2 will be displayed, and movements of the effects faders will be directed to track 2.... etc.

My problem is that the volume faders might be right on the border between two values, and sometimes a spurious value change might happen as a result of a slight vibration of my controllers... say a bump or brushing a fader inadvertently. encoders.. seem to be more stable, but still may be giving me similar problems. In that case, the "target" of my effects changes is no longer correct, and the Live screen is showing me the clip view for the wrong track.

Can someone show me a simple "debouncing" algorithm that I could apply, such that it requires 2 or maybe more consecutive value change messages from a fader to cause Midi Translator to output the changes I described above. Or some other strategy that would get rid of unintentional value changes in the faders. I have many faders ( about 20 tracks) so it would be good if the algorithm were simple.

<<edit -- oops, that wouldn't work since the only time my faders send a value change message is when there is movement of the fader, so if the value changes from, say 13, to 14 and stays there, I might want to use that new value, for volume change, but it would go unnoticed.... so some other way maybe?

Thanks,

Gabriel

Hi Gabriel,

You can use the MOD operator and only send when MOD result is 0

So MOD 2 would be every other 2 Mod 3, every other 3 and so on.

 

Incoming : Control Change CC 7 on MIDI CH 1 value qq

rr=qq%3

if rr!=0 then exit rules skip outgoing action

Incoming : Control Change CC 7 on MIDI CH 1 value qq

Example below:

1: MIDI IN [APC40 mkII]: B0 07 01
2: MIDI IN [APC40 mkII]: B0 07 03
3: MIDI OUT [Bome MIDI Translator 2 Virtual Out]: B0 07 03
4: MIDI IN [APC40 mkII]: B0 07 04
5: MIDI IN [APC40 mkII]: B0 07 06
6: MIDI OUT [Bome MIDI Translator 2 Virtual Out]: B0 07 06
7: MIDI IN [APC40 mkII]: B0 07 07
8: MIDI IN [APC40 mkII]: B0 07 08
9: MIDI IN [APC40 mkII]: B0 07 09
10: MIDI OUT [Bome MIDI Translator 2 Virtual Out]: B0 07 09
11: MIDI IN [APC40 mkII]: B0 07 0A
12: MIDI IN [APC40 mkII]: B0 07 0B
13: MIDI IN [APC40 mkII]: B0 07 0E
14: MIDI IN [APC40 mkII]: B0 07 0F
15: MIDI OUT [Bome MIDI Translator 2 Virtual Out]: B0 07 0F
16: MIDI IN [APC40 mkII]: B0 07 10
17: MIDI IN [APC40 mkII]: B0 07 13
18: MIDI IN [APC40 mkII]: B0 07 14
19: MIDI IN [APC40 mkII]: B0 07 17
20: MIDI IN [APC40 mkII]: B0 07 18
21: MIDI OUT [Bome MIDI Translator 2 Virtual Out]: B0 07 18

The better news is you don't need to consume more global variables. The not so good news is you will loose a little resolution but I think that probably does not matter for your use case.

Steve Caldwell
Bome Q and A Moderator and
Independent Bome Consultant/Specialist
bome@sniz.biz