This increases my workload quite a bit, but I just realized that pin detection (which analog pings are actually in use for a given arduino) and finger mapping (which analog pins map to which fingers) should almost certainly be done at the same time as calibration (what range does each finger use between 0 and 1023?). The steps are as follows: 0) Move all 10 of your fingers Then we watch EVERY analog pin until 10 show movement before moving on and saying "Good" 1) Now move your left pinky in as far as you can back and forth Knowing when to move on poses a problem. We could wait 5 seconds, but what if they don't move their pinky at all? For the OTHER 9 fingers, we could use the pinky (or perhaps right index should come first) as a 'next' key, but that very first finger poses a problem. There's also [...gonna continue writing below...] Repeat for the other 9 fingers 2) Calibration complete ...There's also the problem that they might move the wrong (non-requested) fingers accidentally, so perhaps there needs to be a "is this right?" confirmation or some sort of (visual?) feedback so they know they're mapping their finger(s) to the right pin(s). My plan up until a few mins ago was to have an 11th form of input: a simple pushbutton that says "next" every time it's pressed. But is that an overkill solution? Will that 11th input just sit there and do nothing for the remainder of the wasdf use? Isn't 10 analog inputs FUCKING PLENTY? (yes!) Fuck in all honesty I think I need to sleep on this problem. I never until today considered realtime pin mapping, so I haven't had the chance to let my subconscience tackle it. That 11th input (pushbutton) solution (and the inferior "use first calibrated finger as 'next' button from then on (inferior because how to calibrate first finger?)) have been sitting in my subconscience for years now xD. Hmm ok forelobe'd it: after saying "move your pinky as far as you can", we can simply watch all 10 pins for ~5 seconds and the pinky is the one that moves the MOST. After that we can use the pinky itself as a 'next' key (the threshold for boolean/binary activation should maybe be calibrated before moving onto the next 9 if that's the case TODOmb), or we can simply use the ~5 sec strat for the other 9. Maybe instead of a constant ~5 sec, a min/max timeout should be used: wait a min of 2 sec and a max of 15 sec. Once ~50% range of _only_ 1 of the 10 fingers has been "used"/utilized/calibrated _AND_ 2 sec (min) has elapsed, we move on. But if 15 seconds has elapsed, we'll settle with whatever finger moved the most (maybe a min of 10% utilization though?). If more than 1 finger utilizes >= ~50% range before that 2 seconds minimum, we tell the user to keep the other 9 fingers still and then start the process over (wait another 2 sec) -- loops infinitely until they behave (shit there are people with diseases who literally can't keep their hands still xDDDDD (but there are also people with greater than and less than 10 fingers (and same with the 2 hands assumption!))). s/LeftPinky/RightIndex -- it just makes more sense for right index to be the "next"/confirm/A(in video game console terms)/yes/OK/etc finger rather than the awkward left pinky. After sleeping on it I realized two things: 1) Don't need to have the step 1 above "move all 10 of your fingers". Since we are going to calibrate each finger anyways, pin detection can be done at the same time. 2) The concept of "50%" does not exist until AFTER calibrated. At least not accurately. 0-1023 is the range of the analog sensors, but in reality much less of that range will actually be used (and it [probably] won't start at 0 nor end at 1023, it will be some segment in between) -- that's the whole point of calibration, to determine the range actually used (both by the sensors AND the specific fingers (my pinky has less range than my index finger, for example))! Still there are two solutions (and ideally combining the two somehow would be best): a) the sensor that uses up the most range of 0-1023 is the finger we told them to move. b) the sensor that moves THE MOST (back and forth and back and forth. we keep track of "total distance moved") is the finger we told them to move. I actually like (b) better than (a) and can't off the top of my head think of a way to combine the two, so fuck it (b) it is! (weird I just came up with both (a) and (b) while writing out (2) :-D) #########Ok so to restate the revised design clearly succinctly: 0) Move your right index finger After a couple seconds we select the analog pin that moved the most (total distance wise, not just the one that utilized the most of the 0-1023 range) 1) Either repeat (0) for the other 9 fingers, or use the right index finger from now on as an OK/Next(finger) trigger -- either one works. Fuck deciding now, I'll code (0) first and let it sit in ye ole' subconscience TODOprobably: for step (0) just above there should maybe be a MINIMUM THRESHOLD of an amount of the 0-1023 range being utilized. people with that shaky hand disease might have an ultra fast vibrating finger that gives us a false positive for the "total distance moved". they might go from 0-5 (out of 0-1023) over and over REALLY fast unintentionally... and it might just marginally beat out their _intended_ finger that has a much larger range utilization. this shouldn't be in the first version, since it complicates things too much and is a corner case as well TODOmb: like fps video games give you a chance (and preferably in-game, too!) to "invert" your aiming joystick, I too should give users a chance to change from their RIGHT index finger to their LEFT. My UIs should never say "curl your right index finger to continue", they should say "press [your?] OK [finger?] to continue"