Laser Piano Electronics Suggestions Needed


Alright first, what is a Laser Piano? Well… It’s a piano that has it’s strings replaced with laser beams. When the beam is broken by the mallet, a note is played.

What help do I need? I need help with figuring out how I am going to read 88 signals and translating that into a MIDI or some other output that will allow me output audio. So far the circuit I have built in my head is that the laser will dead end into a photoresistor. Then using a reference voltage across the photoresistor, use the change in voltage to detect when the beam is broken. Then using an ADC converter, take that signal and by using a microcontroller determine how hard or soft the note was played and send that data to some other program to play the note. There are some other cool things I could do with the Optics, but I would need time of flight so If you could help me figure out that circuit as well I’d really appreciate it.


If that’s the route you want to go, look at “Voltage Comparators”. They would allow you to do all of the analog part in hardware, and then you can use trim pots in hardware instead of having to have so many analog channels. 88 digital channels are a lot easier to come by than 88 analog channels.


Alright. Then to follow the Voltage Comparator, I would compare how wide dip/increase in voltage compared to a clock is to determine how hard or soft the note is played?


Unfortunately the digital way is either on or off, so you can’t do comparisons like that. That’s the trade off you’d make for having the speed and availability of digital.

With laser beams though, you should only really have an “on” or an “off”, I don’t think you’ll really get much range even with photo transistors and an analog input.

Have you considered making this a harpsichord ;)?


I can’t really. I already have the upright piano body ready to go.


Not sure this is a “practical” project is since 88 key touch sensitive midi keyboards are available.
As Malcom points out, the opto output will be off/on only.
You can scan 88 sensors and convert to midi w/ micro.
A pedal w/ variable resistor (ie pot) can be used for overall volume cntrl.
The scan and convert will need to be fast to prevent latency issues.
Also scan will need to be able to handle multiple keys hit at the same time - chords, etc.
And keys held while other keys are on/off.
Think the midi format is getting a major update:


This project is being used as a demonstration of optics and teaching optical properties to the community. There are a lot of things I can do with the optics to go beyond on-off, but I’m not sure how to incorporate that with the electronics with little latency. i.e The more optics, the better.


Well short of going the harpsichord route (ie. instrument volume is not controlled via the keyboard) you could get a bit crazy and design a mechanical iris (like the iris of an eye) and have the keyboard control the opening diameter of the iris. Without putting too much thought into this, your original idea of a photoresistor and ADC should work for this.


OK. The mechanical iris would be freakin’ awesome if you implemented it. However, an easier approach might be to have the keyboard control the rotation of a polarizing lens. As the lens rotates, the light transmitted would be reduced/increased.

Note for this approach you would want a linear polarizer, not circular or elliptical. One would need to polarize the light source and then rotate a second polarizer to control the amount of light hitting the sensor.


Both of those methods sound pretty cool. The main problem with both of them is that I would have to replace the mechanisms that already exists in the piano. I mean, getting the polarizer isn’t a problem (Hell I have a giant sheet of it sitting in my desk right now) and I could 3d Print all those irisis. But, I would like to keep the mechanism of the piano itself due to the fact that I am taking 19 credit hours, doing 15 hours of lab work every week, and other things. However, that polarizer suggestion does give me some ideas so thank you for that.


Another idea if you’d like to go the digital route on the electronics with the comparators rather than the ADC would be to have the keys spin a wheel (based upon key pressure). The wheel has a hole (or holes in it) such that it will on occasion line up with the laser beam and on other occasions break the laser beam. And on the far end, you simply receive the signal and count the rate at which the laser light is being disrupted.


One idea - introduce a cylidrical lens across all the lasers. The idea is to spread the laser spots out in the plane of the hammers. Then you use two photo diodes on each beam - one at the top of the oval and one at the bottom. Measure the timing difference between the two diodes being occulted and you can calculate a velocity ( given the distance between the diodes. ). That should be a reasonable analog to key force.


Both of those are great ideas, but HOW DO I READ 88 SIGNALS? I love the suggestions y’all, but my problem is when I get a signal what do I do with it? I can’t find a microcontroller that has 88 pins. I don’t understand electronics enough to do a time measurement without a microcontroller and programming. So, what can I do?


Disclaimer: I am not an electrical engineer, and therefore others might have much better ideas…

You would definitely have a hard time finding a microcontroller with 88 GPIO pins (and 88 might not even be enough without external logic).

If you didn’t need velocity sensitivity and polyphony, you could use something like this:

For polyphony, a crap load of multiplexers and scanning could work (run through each key to see if it’s simply “down”). On or off with no velocity sensitivity.

I have never really considered how complicated velocity sensitivity makes everything. Most velocity sensitivity is implemented by two switches and the time between them being activated indicates how hard the key was pressed (small times indicate harder hits). Measuring all of the timing there would be something I’d want an FPGA for, but you’d still have a hard time finding 176 pins on an FPGA :slight_smile:

I don’t know if you’re dead set on the piano. Maybe consider something simpler like a laser harp (like this: Reducing the number of available notes greatly simplifies all of it. The concept of a laser harp apparently goes back to 1981:


If I can’t end up getting the velocity to work out, I could do that. Thanks for the suggestion.

Sadly I am. I literally went and got the piano Saturday. This is because we have a laser harp demo done, but it is falling apart and I don’t want to keep fixing it. I thought I would make a nice large harp that would last longer, but then I would want to do some intricate carving and I’m not the greatest at carving. So, a piano allows me to use the woodworking I know, show off the lasers, and keep it eye safe.


You may want to consider using an FPGA instead of a microcontroller. FPGAs with > 100 I/Os are common.


So, here’s a design:

  • Figure out your mechanical setup to lessen the intensity of the laser beam focused on photo resistors
  • Get about 11 arduino uno’s
  • Set one up to be a SPI master with 10 slave selects
  • Set the other 10 up for your 88 analog inputs (8 inputs per ATMEGA328)
  • Write custom SPI drivers for your master
  • Write custom SPI drivers for your slaves
  • Worry about analog capacitance and inductance at the polling rate you’d want for “feel” (around 100 microseconds)
  • Write a polling program to poll all of your slaves, grab their analog inputs (which you’ll need to tune for every 88 lasers) and translate that to MIDI
  • Hope that your analog values don’t drift with temp or movement or some other murphy related madness.


  • grab an FPGA with 88 inputs
  • write a simple polling program to generate serial packets to be read by
  • an arduino to do the MIDI
  • be sad because digital is easy and you bought a piano that plays like a harpsichord.


With the FPGAs, 176 inputs should be doable, with time differences between top photodiode and bottom photodiode ( in number of FPGA clock cycles ). ( Speculating heavily - FPGA design is not something I’ve done yet. )