HELP - Digital Piano 72keys ... what is the best solution for so many inputs?

Hi all,

First i have to say that i am a beginner so please don’t blame in case i ask tupid questions XD

My project is the following:

I would like to build a keyboard with 72 keys/switches and thanks to Arduino and a bluetooth board connect it to an IPAD application .
The first step is to have a drawing of the keyboard on the IPAD and when i push one key or several key at the same time the corresponding keys illuminate on the APP.

My question is what is the best way to connect the 72 inputs to arduino and then how to send the signal via bluetooth…???

Thanks a lot in advance for your help!!!


digital piano (847 KB)

For the keyboard, look up keyboard matrix. The matrix could be made using 17 digital pins. You can use shift registers or I2C port expanders to cut down on pin count.

Which iPAD app ? Do you have a link ?

  • The App doesn't exist yet , but the project is about a music training app with external hardware (keyboard). Each of the 72 keys will play a different tone.
  • Yes a keyboard matrix is good option.. I need investigate how to connect the I2C expander to allow to connect 17pins to Arduino.. Thanks ! (as soon as i receive my arduino i will start testing)

For the key inputs, shift registers - nine of them - you can mount each in the middle of an 8-key group. You could even have PCBs made which mount the key switches themselves in groups of 8 for each shift register, and have connectors on each end to chain them. Since there are 12 keys to each octave, there would be three different forms of the PCB alternating along the keyboard.

But with a keyboard matrix , can i push several keys together? like when you play a chord on a piano and you have 3 keys pushed at the same time....

To push and then read several together, one method is to sample all 72 at one time using 9 parallel input shift registers, sampled every so often, or when an interrupt is received when a key is pressed. Then read all 9 bytes in at once using SPI.transfer and act on the keys that are pressed.
For example, here are 4 registers - all inputs read as High until a button is pressed, which will then read as Low.

Whoops! That’s not quite correct - each switch should go to an input, not all to the same one.
Will have to get that fixed.

This is another approach, with diodes - any low button creates an interrupt, use that interrupt to latch the state of the inputs, then shift in and process the data.
If multiple interrupts are used, with PCINT for example, perhaps processing could be sped up to only look at the octave or two where key(s) where actually pressed.

I have a project using a TCA8418 keypad driver. Works with I2C and can be used to up to 80 keys.

Only downside: Pressing 3 keys at the same time, and there in a right angled rectangle shape position a 4th will appear to be pressed. That can be tricky but i managed to set the buttons so it's unlikely 3 buttons in such manner are pressed.

The TCA8414 has a buffer of maximum 10 events. So even when your typing fast and the MCU fall behind, it retains the last 10 events.

EDIT: Now with datasheet! TCA8414 datasheet

OK, there are two approaches that have been described here (and a little confusion as a result!).

I have described one which would be particularly suitable if you were going to use a standard musical keyboard - Using shift registers, you could cover two octaves per three shift registers and you would use three such modules (or three sets of three "building blocks" with a shift register each to make the size of the PCBs more manageable) to cover your six octaves. Total nine Parallel-in, Serial-out shift registers.

If on the other hand as your drawing suggests, you merely want a "box of buttons", then matrixing is a logical approach. You can use a decade counter (4017) to scan ten "columns" (which need not be the same number as the columns on your box of course) and an octal shift register - same as in the first method and requiring eight pull-downs - to read the rows, thus up to 80 keys.

Now in regard to multiple keypresses, this does not matter at all for the pure shift register solution since every key goes to one input (and you need a pull-up for every one). With the matrix, the 4017 pulls up one output at a time, pulling the others down, which is a little inconvenient. There is a possibility of two keys being pressed, shorting two columns together.

The first solution to this is to have each output from the 4017 pass through a diode so it can only pull the column line up. This however does not solve the concern about three keys as "corners of a square" in the logical matrix, being pressed and causing a "phantom" of the fourth "corner" effectively being pressed as well.

The more consistent solution, in fact the only complete solution to this problem in a matrix, is to have a diode on every key so that it can feed from a column to a row, but not the other direction. Since diodes cost one cent each, this is hardly a problem.

Great.. thanks a lot for the inputs. I have now my arduino in hands and first i am learning with some simple examples before to go to my e-keyboard which is more complicated ....

What about port expanders instead of register shift?

could i use the arduino to scan 5 of those port expanders?

And then send the key code to the EZ-Key (bluetooh keyboard controller) which will send them via bluetooth to the ipad app ?

Regards Matute

It's still a shift register.

What about port expanders instead of register shift?
Could I use the Arduino to scan 5 of these port expanders?

You certainly could, though you would lose the modularity I suggested. As you can define an I2C address for each and have 8 options, then five would do quite nicely. I don’t know if they have the pull-ups built in.

The simple shift registers will be about one tenth of the price of course.