plz help me with choosing a MCU

[NorthGuy]

Don't report a 2nd (3rd, 4th) button press within the debounce time, but why delay the initial press at all?

To filter out glitches, not real button presses.

[brucehoult]

Don't report a 2nd (3rd, 4th) button press within the debounce time, but why delay the initial press at all?

To filter out glitches, not real button presses.

As I said, that's a different thing than debounce.

Under what circumstances will your debounce code not send the keypress at all, after an initial trigger happens?

[Psi]

Yep, when you already have capacitor across the button input then any random noise has to discharge the cap to get the input low enough to trigger a false button press. So you're normally not concerned about proving the first high to low transition is a legit button press. You just assume it is and process it when it comes in. You have a hold-off time to block any more high-low transitions from being processed in some amount of ns/ms after a previous one.

You could implement debounce protection as a min-button-down time that must be met, but that adds latency from button press to process logic, and you can miss legit button presses if the user is extremely fast. So the min-button-down time approach is not a good idea unless you have a valid reason to do it.

[NorthGuy]

As I said, that's a different thing than debounce.

May be. Does it make any difference?

Under what circumstances will your debounce code not send the keypress at all, after an initial trigger happens?

It requires 3 consecutive '0' readings to confirm the button pressed. If there is only one or two, it won't react.

[brucehoult]

Under what circumstances will your debounce code not send the keypress at all, after an initial trigger happens?

It requires 3 consecutive '0' readings to confirm the button pressed. If there is only one or two, it won't react.

How long for those three readings?

Oh, you said 10ms delays. So 20ms for 3 readings.

If you get ...1111000100011111... then how many button presses do you forward to the higher level software?

[NorthGuy]

If you get ...1111000100011111... then how many button presses do you forward to the higher level software?

One. To confirm the release it would need 3 consecutive '1'.

[westfw]

Wouldn't you normall just poll buttons every 20ms or so?  The chances that there would be a "glitch" RIGHT THEN is very small, and the chances of missing a button if you thought 30+ms was a reasonable "debounce time" is also small.

If you want, you can use some sort of pin-change interrupt or timer capture to indicate that one in a some set of buttons has been pressed, so you can skip some of the polling.  But OP said 8 voices, so the max number of simultaneous button presses is probably pretty easily manageable.

Or, you know, you could use a computer keyboard (or the decoder from it), and it will do the debouncing for you, giving both "press" and "release" indication.  (though I'm not sure whether they'd handle 8 simultaneous presses.)

[Tation]

Musicians will find 25 ms of latency not acceptable, notes will not be "in place".

That denouncing strategy is, simply, not feasible here. Use better the other one proposed here: a cooldown period after each detected rise/fall edge, a time tested strategy.

Pro gamers will also not be happy with a 25 ms latency.

[Psi]

In most cases if the user pressed a switch down enough for the contacts to touch then it's a legit press.

You will always get the situation where someone pressed a button with a very light force and the contacts only touched for some absurdly small amount of time.
So a min-down-time approach will usually result in failure to detect legit presses.

[tooki]

I don't think a synthesizer is a critical real-time stuff. You can add considerable delay between generation and playing, as long as you have space for a buffer.  For example, if you have a 1000-point buffer  (roughly 20 ms at 44 kHz), it is perfectly OK if calculation of some points will take much longer than 4000 instructions, as long as you don't exceed 4000 on average.

Just FYI, for a synth, 5ms is considered the maximum tolerable latency by the sources I saw. I don’t know what your threshold for “considerable” delay is, but 20ms is certainly too much.

Maximum tolerable by whom? I think you could raise the total latency to 50ms before it becomes a significant problem. Just from my limited playing around with digital audio. I haven't made a musical instrument before.

Tolerable by musicians, producers, sound engineers, DJs, etc. This is stuff that’s been understood by people in the music production world for decades.

Essentially, you have a latency budget, and everything in your signal chain that adds latency eats up some of that budget. So you have to be conservative in adding latency, since you don’t want to eat up so much latency that there’s none left for anything else. For example, using a USB audio interface adds several ms, eating into your latency budget.

One reason why Macs are so dominant in music production (DAWs, digital audio workstations) to this day is that prior to Windows 10, Windows had significantly worse audio latency than Mac OS X did (whose audio stack was explicitly engineered to be low-latency). Microsoft itself says that Windows 10 reduced round-trip (capture->audio engine->output) latency in existing apps/drivers by 4.5ms or 16ms (depending on which data format was used, integer or floating-point), and added the ability for apps/drivers to reduce latency further by allowing them to adjust buffer sizes. For context, typical settings in Logic Pro (Apple’s DAW app) produce round-trip latency of around 10ms, so Win 8 and earlier were way worse, since you could shave off more than that! Win 10 and 11 produce latency comparable to macOS.

For reference, you will add 5ms of latency by simply being 1.5 metres further away from the sound source.

Right. Why do you think recording studios use headphones primarily? For example, suppose you’re recording a track (voice or an additional instrument). The tracks you’ve recorded so far get played through headphones, so the musician in the booth “syncs” to that, and the recording engineer in the control room hears both through their headphones or through near-field studio monitors.

An upright piano has significantly more lag in its mechanical action. I haven't measured the delay the action introduces compared to an electrical switch, but just by looking at it I'd say it's at least 20ms and it's more when played softly.

A piano’s action (the mechanism that follows the keys and moves the hammers) can have significant (~200ms) mechanical latency and hysteresis, but those are things a pianist will have accustomed themselves to over the course of years — and pianos do not have the sharp, immediate attack of some other instruments.

A synth generating such a fast-attack instrument (or synthetic sound) doesn’t have the luxury of some latency wiggle room.

[tooki]

An interesting question is how real-world synthesizers deal with denouncing/deglitching (henceforth just “debouncing” to mean both). All but very basic synths use velocity-sensing keys (mostly by having two or three switches per key, not just one; some very high end models, like the Yamaha AvantGrand digital pianos, use optical sensing, using non-contact fiber optic on/off optocouplers instead of electrical switches, and also an analog sensor (either an optical density sensor and a gradient “flag”, or electromagnetic sensing in newer models). So when debouncing, what logic do they use? Do they debounce each switch individually? Or do they look at the other switches, too, and use more complex logic rules? Or both? When does playback begin?



Also, one thing that people designing user interfaces don’t always realize: a “button press” means different things, depending on context, in the sense that for some applications, you want to act on the “button down” event (for example, a gun trigger), on others, on “button up” (like a standard typing keyboard keystroke). And of course then you add functions like long presses that get evaluated differently again. How you debounce in code depends entirely on which of these features you need to implement.


My boilerplate button processing code (which is normally separated from the polling or interrupt that actually reads the GPIO state) uses elapsed time measurement, and has events for button_down (zero delay), short_press_down (after a short debouncing delay, e.g., 10ms), short_press_up (button released after short_press_down), long_press_down (after a much longer delay, e.g. 1s), and long_press_up (button released after long_press_down).

You can, of course, add multiple time thresholds, for example on up/down buttons for setting values, where you want it to increment by one on short_press_down, then after being held for e.g. 500ms repeat incrementing by one every 100ms, then after being held for 3s, change from incrementing by 10 every 100ms, and after being held 6 seconds, change to incrementing by 100 every 100ms.

[ledtester]

There are a lot of synth projects bult around the RPi Pico...

Just a few links...

A polyphonic wavetable synthesizer library for the Raspberry Pi Pico 2
- https://github.com/raybellis/PicoSynth

64 Knob Virtual Analog Synth:
- https://hackaday.io/project/204220-64-knob-virtual-analog-synth-on-pico-2
- Demo videos at https://www.youtube.com/@hioyama

Digital Synth PRA32-U
- https://github.com/risgk/digital-synth-pra32-u
- Demo videos available on youtube - search for "PRA32-U"