piano midi controller diy

scherbakov.​al
As far as I can tell, "the slowness" - if any - really comes from capacitance of phototransistors.
Most HC series ICs are fast by themselves (for our requirements anyway!).

CD4051 1-to-8 analog muxes work without any issue whatsoever switching at 160kHz (meaning each sensor 20kHz)
The HC238 also work well, but in the circuits I drew previously the adjacent sensor readings influence each other somewhat (which might be ok for slit sensors, but not for the analog ones). So those hc238 circuits are incomplete and need improvements that fully address the capacitance and properties of phototransistors.

One of the big goals with using HC238 was to cut down power consumption below 500mA, such that it can directly be powered by USB.

I was also thinking that it might be possible (?) to have all leds be constantly on and still be under 500mA budget.
Regular phototransistors has forward voltage of ~ 1.2V, meaning you could one LED current limiting resistor per two sensors in series.
If we're aiming for around 9-10mA for each led, that would give us ((3.3v-(1.2v * 2))/100ohm) * 44pairs = ~ 396mA. (5V->3.3V via LDO)
Few mA for MCU and ~ 30mA (3.3/10kohm)*88 pullups/pulldowns - and even the basic-always-on CD4051 muxing version might work just from 500mA USB?

Time has shown that the ability to calibrate sensors is an important and necessary function. It turned out that there are digital resistors. (Mcp4351). I learned about them recently. I decided to try to add them to the existing circuit. I assume that adding these digital resistors would add 3 more (maybe 4) communication lines from the central controller to the boards with sensors. They are controlled via SPI. There are options for i2c control, there is an option with memory and without. I learned to control resistors, it is not difficult. I sketched out a circuit and sat down to redo the board layout.

But it turned out that some stm32 can contain a comparator. For some reason, I did not pay attention to this before. I searched and found stm32g473, which have 7 comparators and 7 DACs on board. It seems that the DACs can be used to set the comparator response point programmatically. Now I'm waiting for several stm32g473 for training and testing. I'm also interested in the analog multiplexer. But not ch238(It turned out that it connects one channel into many, but SN74LV4051). I tested its operation at a speed of 1 MHz. (Switching channels with a frequency of 8 MHz and running the entire circle for ~ 1us) and the result does not satisfy me yet.

At such a speed, the channels influence each other too much. I will come up with some other connection scheme and test. This is exactly the scanning speed I would like to achieve (it would be 3 times faster than the option with shift registers). If it worked out, it would be nice.

@DavisB - what if you switch to USB 3? It supports power supply up to 3 amperes.

The homemade MIDI piano controller has been updated. The controller is now more compact, has a color touchscreen, connects to the boards using a pair of FPC cables (getting rid of the clutter of wires), and has a distance calibration function for the sensors. Assembles without soldering. Hi-res midi is now more accurate (expected range is somewhere around 0-14000 speeds). It still features super-low latency.

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

I've also upgraded to pretty much exclusively FFCs cables in my designs (in a similar manner)
Started with 2.54mm duponts -> some designs with 2.0mm PH connectors -> into fully embracing 0.5mm/1mm FFC cables and FFC connectors. Turns out both connectors and cables are pretty cheap, and very easy to assemble. 1mm FFC connector is also very easy to solder.

Similarly I started with passives in 1206, now I'm using 0805 and even 0603, etc.
Another thing useful thing is using 1x8 resistor arrays for designs that require "spamming resistors", although SMT assembly services are so cheap that there's no reason to stray away from designs that have large parts counts (as long as these parts are on the same reel).

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).