I want to make a MIDI controller from a real grand piano action. I haven't yet decided what type of sensors I will use and there are many options. For example some of the commercial solutions (Yamaha/Kawai) use a small rectangular shutter on the hammer stem that passes through an optical pair and the velocity is calculated using time. In another solution (Alpha piano) the hammers strike a strain gage.
Anyway, I think I might go for optical reflective sensors such as the Vishay CNY70 that measures the distance from a reflective surface.
Since the sensor generates an analog output (output current is dependent on the object distance) I need to decide how I should calculate velocity. One idea I have is to just define two current thresholds (e.g. distances, d1, d2 on the picture) from which to calculate the time.
I haven't yet bought a Teensy and I'm wondering whether it will be quick enough to do that calculation. One idea I have is to feed each of that signals to a digital IO and use the interrupts. I will use two inputs from the hammer sensor (corresponding to two distances) and one from the key (only on/off). So, these are three inputs per note, meaning I can use one Teensy (58 inputs) for 19 notes, i.e. I will have to use 5 Teensy boards to cover all 88 notes. I will have one more Teensy to act as a master and send the MIDI messages, polling the other boards through SPI/I2C.
Do you believe that a single Teensy board, using interrupts would be fast enough to calculate velocities in this way? For clarity, a hammer may reach a velocity of up to 10m/s and the two measurements should be done as close as possible to the strike point (because that's where the hammer detaches from the key, otherwise its speed might be variable due to key not being pressed with the same speed across its path). So, let's say I need to measure the last 5-10mm of the hammer travel. If we take the worst case: 10m/s in 5mm, that means a duration of 500us. In order to be able to precisely interpret that, I guess each interrupt processing should take no more than 250us. But then, it might have to process also all other notes (and the key), i.e. all 57 sensors/interrupts. And that brings it down to just 4us which to me seems like impossible
Do you think my calculations are in any way flawed? If not, does that mean that the only way to correctly calculate velocities from so many sensors is to dedicate a PIC controller or something else at each note?
Do you believe I can implement the whole thing in an entirely different manner? If I go for strain gages, how can I detect the max strike force related to each hit (which will be a huge chatter around a short duration) and how many ADC should I have in order to process all sensors in reasonable time?
Any advices will be appreciated.
Anyway, I think I might go for optical reflective sensors such as the Vishay CNY70 that measures the distance from a reflective surface.
Since the sensor generates an analog output (output current is dependent on the object distance) I need to decide how I should calculate velocity. One idea I have is to just define two current thresholds (e.g. distances, d1, d2 on the picture) from which to calculate the time.
I haven't yet bought a Teensy and I'm wondering whether it will be quick enough to do that calculation. One idea I have is to feed each of that signals to a digital IO and use the interrupts. I will use two inputs from the hammer sensor (corresponding to two distances) and one from the key (only on/off). So, these are three inputs per note, meaning I can use one Teensy (58 inputs) for 19 notes, i.e. I will have to use 5 Teensy boards to cover all 88 notes. I will have one more Teensy to act as a master and send the MIDI messages, polling the other boards through SPI/I2C.
Do you believe that a single Teensy board, using interrupts would be fast enough to calculate velocities in this way? For clarity, a hammer may reach a velocity of up to 10m/s and the two measurements should be done as close as possible to the strike point (because that's where the hammer detaches from the key, otherwise its speed might be variable due to key not being pressed with the same speed across its path). So, let's say I need to measure the last 5-10mm of the hammer travel. If we take the worst case: 10m/s in 5mm, that means a duration of 500us. In order to be able to precisely interpret that, I guess each interrupt processing should take no more than 250us. But then, it might have to process also all other notes (and the key), i.e. all 57 sensors/interrupts. And that brings it down to just 4us which to me seems like impossible
Do you think my calculations are in any way flawed? If not, does that mean that the only way to correctly calculate velocities from so many sensors is to dedicate a PIC controller or something else at each note?
Do you believe I can implement the whole thing in an entirely different manner? If I go for strain gages, how can I detect the max strike force related to each hit (which will be a huge chatter around a short duration) and how many ADC should I have in order to process all sensors in reasonable time?
Any advices will be appreciated.