debouncing dirty switches

I may be an idiot (good way to start, yes?) but I have a mental block on how to do this... I am using the analog inputs to detect state changes between some switches. The problem is, the switches aren't exactly "precision electronics" and each state change in the switch triggers several "changed" messages. I am using the code: mcflash.onMessageIn = function( msg:OscMessage ) { //trace(msg); var value:Number = msg.args[0]; switch( msg.address ) { case "/analogin/0/value": // check to see if the old value is still the same if (value != ain0olderValue) { trace ("changed 0"); _root.gotoAndStop ("FrameMarker"); } // save the current value as the new old value ain0olderValue = value; break; // more nearly identical case statements to deal with other pins... } } So, inside of each case, I need to wait about 100 milliseconds or so to check and see if value is still not equal to the ain0olderValue, in order to wait for the switch noise to pass... Make sense?

Well, the simplest answer is probably "get some better switches" Beyond that, I think you will indeed just incur a little less responsiveness for your app in order to wait some period of time after an initial trigger to wait for it to settle down. 100 milliseconds sounds like a long time to wait, but I don't know how badly your switches are misbehaving...

Heh.  Well, if the switches could be removed without major surgery...  and if i could find something that would replace them...

Maybe I wasn't super-clear, but my question is, how can I code the wait?  The onMessageIn function is firing every frame, so I can't really delay inside of that function, can I?  And the next fire of onMessageIn may or may not have a transition as part of it...  Do I need to use setInterval from inside onMessageIn or something?  It seems like onMessageIn needs to save that a transition has (maybe) taken place, then halt calls to onMessageIn for a few millis, and then call it again and see if the transition has still taken place...  Is this right???  Sorry, I have been thinking about this for a while, and I feel like I am missing something really obvious about how this should work.

I'm by no means a Flash guru, so maybe somebody else can chime in with the actual best practices. Probably the simplest would be to count frames. Once you get a transition, start counting and if you reach some threshold only then trigger your action. If you get a re-transition before then, cancel it. Getting fancier (but also perhaps less possible), I wonder if there's a way to fire off a delegate function for some time in the future? If so, in the message handler you could check to see if any previous delegates had been fired and if not, fire a new one. If the state changes back within your time threshold and a delegate has been fired but not yet activated, you could cancel the delegate.

OK, I said that it was a brain-block. The problem was solved when I talked it through to myself out loud. The bounces were all under a threshold of about 70 units -- according to make. We just needed to pay attention to changes that were over 100 units. if (Math.abs(value - ain0olderValue) > 100) { trace ("changed 0"); _root.gotoAndStop ("FrameMarker"); }