Switch::Debounce() not working reliably on Patch Init button?

I recently acquired a patch submodule and init() and have been greatly enjoying exploring its capabilities. However, I am having some trouble with the push button on the module (aka pin B7) - specifically using Switch::Debounce() followed by Switch::RisingEdge() inside an audio callback.

I notice that it’s pretty unreliable to detect a single button press this way, e.g. for advancing an internal “mode” selection in the patch. It seems to double-press about half the time at higher sample rates.

Is there a better way to do this using the existing libDaisy capabilities or would I be best served by implementing some kind of additional debounce logic?

1 Like

I found a workaround which is to process that button (and the logic it triggers) inside an infinite loop in main() with a 1ms sleep interval instead of in the audio callback. My best guess is that the 8-bit shifted integer used for debouncing in Switch is just not enough bits for that algorithm to work well when the button is being read every time the audio callback is invoked. Reading it that frequently isn’t necessary anyway.

1 Like

This is a good point – most callbacks were originally being run at 1ms, so they probably would have been very stable – I think some boards default as high as 12kHz (~83us) now, and the 8-bits might not be long enough to store that.

Your workaround will definitely work. A universal solution that kept the callback rate in mind would be great (since often times you can just run the callback at 1ms/1kHz and 8-bits is enough, whereas 32-bits would be on the cusp of noticeable latency for presses/releases).

Depending on what you’re doing you can change the callback rate using DaisyPatchSM::SetAudioBlockSize(size), the size being the number of samples per callback. So at 48 samples w/ 48kHz audio the callback is at 1ms, etc.

1 Like

Thanks for the info! I did see there’s an obsolete update rate param in the Switch class that maybe at one point was handling some of this?

In any case - I’m running a patch at 96kHz and love the fact that nearly all controls and modulations can update at a quarter of that with no issues (block size 4). I do wonder if there’s a way to intelligently detect how frequently the denounce method is called in order to proactively throttle if it’s too fast for the 8 bit shift debounce?

Having this same problem right now. I was already checking for button presses in an infinite loop in main but I’m not totally sure what you mean by a 1ms sleep interval. How do I accomplish that?

Just add System::Delay(1); to the while loop

1 Like