I am modifying an old 90s keyboard (CTK-450 by CASIO) to make it a MIDI controller. I'm going for an Arduino that goes over the matrix layout of the keyboard.

The issue I have is with debouncing. Now I know the best idea would be to add some small capacitors in there to make sure there are no issues with bouncing switches, but I'm wondering whether I could just ignore the problem. My reasoning is as follows:

  1. I don't really care if I get bogus input, as it's a MIDI controller. It isn't some button that deals with menu scrolling or what not.
  2. The RC circuit on the original PCB for the keyboard is R = 1kOhm, C = 1nF or 0.1 nF depending on the exact circuit, which gives me a time constant t <= 1µs. I'm going to be polling the keystates at a much slower rate to start with (Arduino digitalRead() takes 1-4 µs, and I have to go over around 60 keys plus some overhead), and it's extremely unlikely that the reading will happen exactly at the time the key is in a bouncing state.
  3. Even if I manage to sometimes read the key while the signal is bouncing, it shouldn't really matter. If I read logical low when I just pressed the key, by the time I go through all the keys again, the bouncing will have stopped and I will have a solid digital high to read, and vice versa.

I think the key to this is the fact that the time constant for the RC debouncing filter is so small. Is it really believable that the switches in the keys will have such a short bouncing time? I understand the bouncing time doesn't necessarily have to be the exact same as the time constant, but even if it happened to be a bit bigger, assuming it's around that order of magnitude, arguments 1 and 3 still hold, I would assume.

Thus, can I completely avoid putting those debouncing caps into the circuit, even if in principle, it isn't a good idea for every situation?

  • 1
    \$\begingroup\$ I'd argue that you'd debounce something like that in software. Easier. \$\endgroup\$ Commented Feb 10, 2020 at 18:48
  • \$\begingroup\$ If it comes to that, I'll do it in software, yes, but I really have doubts about the time constant still. \$\endgroup\$ Commented Feb 10, 2020 at 18:51
  • \$\begingroup\$ "I don't really care if I get bogus input, as it's a MIDI controller. It isn't some button that deals with menu scrolling or what not. " - No, that is definitely not the case. Most real world and many synth instruments have different sound qualities for attack, decay, sustain, and release. Banging a piano key 5 times a millisecond apart will sound dramatically different than 1 attack with a sustain. Do it the right way the first time. \$\endgroup\$ Commented Feb 11, 2020 at 3:15
  • \$\begingroup\$ @whatsisname Oh, definitely, yes, it's better to do it alright the first time round. I probably will end up debouncing it in software if it causes any issues, or simply decreasing the polling rate to something where bouncing doesn't have much of an effect, maybe around 2/3ms, as was advised in the accepted answer's comment section. I'll have to see. \$\endgroup\$ Commented Feb 11, 2020 at 15:29

1 Answer 1


I guess the 1us RC lowpass filtering tries to keep off false keyhits caused by phones and other radio transmitters. The debouncing is performed with software.

Do not add slowness to the circuit which detects if a key is pressed. Players hate delays. There's enough it already (MIDI transmission,communication between the MIDI interface and the computer application, sound generating DSP, sound system DSP, distance to the loudspeaker). As much as 20ms total in circuits (+ the distance to the loudspeaker) is well achievable by bad design and it makes a MIDI keyboard painful experience for a competent player.

Make your system to react as soon as possible to a keypress. Leave debouncing delay for the key scanning software and let it affect only to the time when the releasing of the key is taken into the account. Playing a sound a little too long is much less annoying than a delayed start.

A simple debouncing strategy in software is to scan the keys say in every 3 millisecond if the caused 0...3 ms extra delay is not a problem. The maximum value 3 ms is equivalent with about 1 meter extra distance to the speaker which can be acceptable.

  • \$\begingroup\$ The issue would be repeat note on, note off messages, which might make velocity hard to compute. \$\endgroup\$ Commented Feb 10, 2020 at 20:43
  • 2
    \$\begingroup\$ @ScottSeidman how the velocity is calculated without 2 contact switches or a hit strength or velocity transducer? \$\endgroup\$
    – user136077
    Commented Feb 10, 2020 at 20:54
  • \$\begingroup\$ That will be MIDI instrument dependent. music-software-development.com/midi-tutorial.html. It might just be a scaling of the peak value on an aftertouch sensor at the moment of a note on. On a wind controller, it might be an air pressure sensor. W/ repeating on\offs, that sensor value may be attenuated already. \$\endgroup\$ Commented Feb 10, 2020 at 21:17
  • \$\begingroup\$ So if I can avoid debouncing on the key press, I could also avoid it in principle for the key depress, and just let the thing play a cycle longer, which shouldn't be that much. This means I can leave debouncing completely out of the loop? \$\endgroup\$ Commented Feb 10, 2020 at 21:36
  • \$\begingroup\$ @ScottSeidman I luckily won't be computing velocity, but I also think I shouldn't suffer from repeated note on and off messages as per arguments 2 and 3. What do you think? \$\endgroup\$ Commented Feb 10, 2020 at 21:39

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.