piano midi controller diy

DavisB Do you use analog sensors + ADCs now? Or DAC + comparator method?
How does your new version work? Which MCU do you use, still stm32h7xx?

Currently, i using a DAC + comparator in stm32g474 chips. And everything is controlled by an stm32h723. To be honest, it works amazingly!

DavisB I've also upgraded to pretty much exclusively FFCs cables in my designs

Yes, this turned out to be very convenient. It's great that these connectors are easily installed at the factory along with other components on the board. I also really liked these solderless power connection terminals (also installed at the factory):
https://file.elecfans.com/web2/M00/72/51/poYBAGNVYTiATYCUAAiIHsQDSQ0713.pdf

scherbakov.​al
How many sensors per stm32g474 do you use?
Or do you mux multiple sensors into those 7 comparator pins?

In the most extreme case (without muxing) it would be 1 sensor directly into each comparator pin (stm32g474 has 7 of those and 7 DAC outputs internally wired into one side of comparator). If you mux comparator inputs, you can of course do way, way more....

DavisB
I use 1 sensor per 1 comparator - a total of 7 sensors per 1 microcontroller. Without multiplexing.

Out of curiosity, I simulated the movement of electron field waves along the circuit board currently used in my piano design. I used only open-source software: KiCad, FreeCad, OpenEMS, GnuOctave, ParaView, and Linux. It was quite interesting and engaging.

https://github.com/ScherbakovAl/PIANO_H7

https://github.com/ScherbakovAl/PIANO_G4_cbt6

Here's a new version of the controller. The repository isn't very neat, the code looks like wet hair in the wind, with a lot of abandoned work. But it works. It does its job very well. There's now a touchscreen.

You can calibrate the sensor trigger points.

A bootloader has been added - the main controller can be flashed directly via USB, without a programmer. And all microcontrollers with sensors can be flashed from the main controller.

I played around with the velocity curves - in the end, I liked the option of calculating the hammer energy based on its mass the most. It seemed more plausible.

The keyboard response latency is still low - 30-50 microseconds. Hi-Res MIDI support - I estimate there are around 6000 velocity levels, maybe more. Currently, my sensors are mounted above the hammer felt. And I'm getting some minor crosstalk. They work in such a way that if two adjacent hammers move in the same direction, their velocity can increase slightly. I'm thinking of either painting the sides of the hammers with non-reflective paint, leaving the "working" space under the sensors, or moving the sensors to a different location on the hammer. I don't know yet, we'll see.

I also made a wavelet analyzer. Just out of curiosity. It allows you to examine phases, something you usually don't see in spectrum analyzers.
https://github.com/ScherbakovAl/wavescope

I was able to participate in an interesting event with this keyboard project. I modified my controller to fit under the keys of a Bösendorfer grand piano.

The piano was played by a pianist—the grandson of the artist Kandinsky. At the same time, a video sequence based on Kandinsky's ideas about the connection between form, color, and sound was generated by the computer from the piano keys. It was a pleasant event and a great learning experience for me.

scherbakov.​al

Modified, as not at the hammers, rather under the keys (levers). What is the difference? Any videos?
Are those sensor just to detect velocity? 30 to 50 μs is good latency. 6000 velocity levels is over the top enough.
Proximity sensors? How the keys now (not hammers) hit the sensors? In a video above you show a hammer (held by your hand) hitting the sensors. How is it modified now (with proximity)?

PASHKULI Modified, as not at the hammers, rather under the keys (levers). What is the difference? Any videos?
Under the keys—that's enough for visualization control. And sensors above the hammers are redundant in this case. Having sensors above the hammers is important for the pianist—to achieve good control and feedback from the action. Which was not required in that case. I can't post a video.

PASHKULI 6000 velocity
this is the base!

PASHKULI How the keys now (not hammers) hit the sensors?
The hammers barely reach the sensors - they are stopped by the stop bar

It is assumed that for playing, the sensors are above the hammers (above and below, as you wish) - to read the impact, and above/below the keys - to work with the dampers. The damper's "fall" speed is also present.

Incidentally, the problem is that if you make sensors for the keys, they'll fit the vast majority of vertical and horizontal keys—the key width is more or less standard. However, to position the sensors near the hammers, you'll likely need to custom-make them for each instrument model. The internal layout of instruments can be quite flexible.

For example, for a home instrument, boards were made with the distance between the pickups for the bass hammers being 13.55 mm, the left midrange being 13.37 mm, the right being 13.2 mm, and the treble being 13 mm. Otherwise, everything would have drifted apart. The number of hammers per section also varies greatly among different instruments.

I see. So, it seems those are proximity sensors. But how would they detect the felt of the hammer if not touched\hit by it? Do you attach anything on top of the felt of the hammer? The hammer has a velocity at a given point. Does it mean that the sensor needs a minimum velocity (therefore proximity to it) by the hammer in order to set a minimum ppp (pianississimo) for example? Because fff (fortessissimo) is the closest\fastest maybe? So how the 6000 levels come to fit such setup?

PASHKULI
qre1113 - an infrared LED shines on an object(hammer), a phototransistor captures the reflected light and changes the current through the collector-emitter. It operates from 1 to ~ 10-12 mm. No touching is required. The minimum speed is taken from the moment the hammer begins to reach the second actuation point (string contact). The maximum is at the limit of the instrument's integrity. There is a maximum speed limit, where increasing force on the key no longer results in faster hammer movement—the system springs and bends, deforms, and flight speed is not increased. However, the risk of damaging the keyboard increases. This speed range is determined by several thousand gradations.

scherbakov.​al

Aha, got it. So, technically for lower dynamics the hammer does not need to travel all the way "up" (as would usually touch the real strings) but close enough of at least 12mm from the sensor. Correct?

This is very different from real acoustic\mech. play, where the hammer will have to always touch the string. Infra red are "long" wave lengths (up to about 1mm). Interesting how those can bounce off of a felt.

Wouldn't it be possible to mount it at the shank, above its base near the point of rotation (or maybe just pass where the knuckle is on an Erard's action) where the length of he arc (vertical secant) will be in the 12mm range?

• typically the shank is horizontal when the top of the hammer's felt hits the string
• maybe the sensor hanging from about 15mm so it can possibly capture a acceleration too

Lower (quiet) dynamics happen when the hammer is decelerating, louder when accelerating even pass the horizontal line (then bouncing off of the string). Wouldn't such construction be more accurate? Technically, the sensor (gray rect. with three dark legs on the illustration above) should be able to capture even small bouncing of the hammer (before it reaches horizontal position). By adjusting the sensor's position horizontally such behaviour could be regulated or in combination with software "accel.\vel. curve".

Only the hammer's passage through points at a distance of ~ 3 mm and 1 mm from the sensor is measured (plus or minus, adjustable). Tracking the entire hammer range is not required. Technically, it is possible to monitor the entire range of hammer motion, but why bother? (You could use this information to model damper behavior, but I prefer separate damper sensors.) Speeds lower than those at which the hammer reaches the string can be recorded. But why bother? I don't see the point. Pianists don't play silently (usually). Perhaps only to use unconventional playing techniques. You can install sensors anywhere on the hammer—whatever you prefer. A quiet sound is produced when the hammer slows down at a slow speed, and a loud sound is produced when the hammer slows down at a fast speed. When approaching the string, the hammer is in free flight for the last couple of millimeters and is only slowed by air friction, friction at the pivot point, and gravity.

scherbakov.​al

For loud sounds the hammer does not need to decelerate at all. A quiet sound with a hammer mechanics is only possible when it already has been decelerating due to gravity (mainly + the tiny friction within the construction elements).

In a experimental setup lets say the pianist only makes a slight impulse to the knuckle. The hammer accelerates to overcome its own weight + additional acceleration for some louder dynamic. But if that additional acceleration is such that the hammer's felt barely touches the string → then we have a very quiet sound. Such technique is very difficult on piano (almost none can pull it off probably) especially in fast tempo (short notes in a row).

I assume with your setup and what I suggested above such playing (very piano) should be possible. The problem then though will be that there are no sample libraries with such gentle (piano) samples. They probably use just volume + EQ adjusted louder ones (as recorded).

And therefore, that is why I also do not like the available sample libraries. On the other end of the range the overly louder samples typically cause nasty self resonances (shown in the other threads of the forum).