Another DIY hybrid

sawyer bergeron nice progress and cute cat 🐱

To minimize the bump you need to:

1. Set the jack position as far backward as possible for it to work properly, (too far backward will work for pianissimo playing but may slip from under the knuckle at forte blows)

2. Set the drop as late as possible, when drop is set later than highest point of letoff, there is no bump (and so no problem with extreme pianissimo), it can't be set that way in acoustic piano because there is aftertouch and that causes repetition lever to rise above the letoff point and so hammer to rise and block to the strings, but maybe you could take this into consideration in software, you can think about it

3. Lubrication, fine teflon powder works best, but it doesn't stick very well to the knuckles (actually it doesn't stick at all lol) but with repeated applications some of it stays deeper in the surface and stays a little longer, wet lubricants are little risky and can make a mess, I personally don't use them.

And of course you need first to set other things close to where they should be, letoff, repetition spring (at least to be strong enough to hold the hammer for now), repetition lever height (can't set it properly if spring is too weak) and aftertouch. Try to set one sample note and play with settings, you may get some understanding this way, do not try to set all the keys to some standard that you find in some book or somewhere without any thought because it will fail most likely as this is not a new action and standard settings will not work well.

sawyer bergeron

Nice to see the project progressing!

stem piano applies an exponential curve fit. I put calibration in run-time, and it estimates parameters automatically when play piano.

To see the code algorithms, start at component link below and then follow link for "StemPianoIPS2 Firmware" about 3/4 way down the component file. The source code is calibration_position.cpp.

(I didn't link directly to the .cpp file because "DIY" repo links may change in future as migrates to stem piano repos):

https://github.com/stem-piano/stem-piano-g-main/blob/main/documentation/component_manual.md

Calibration for the sensors works pretty well, though getting "perfectly" even key velocity measurements might take an additional measurement step. So far, calibration is just "lift each hammer all the way up, and then let it fall", which takes ~1-2 minutes for 32 keys. Hard to tell how much unevenness is just because the entire thing is bouncing all over the place on the current stand.

https://youtu.be/siqSPc1QJVQ

Returning to this after quite a while, some updates:

The original architecture was a cool proof of concept for the idea itself, but I think needs a rev2 at least, and I'm pretty much completely redoing the software.

A bit part of the problem has been trying to fit "everything" onto the one teensy. The muxed ADCs on it are, combined, plenty fast and have a perfectly sufficient SNR when doing smoothing/resampling. The problem is that 512k of TCM, even with the additional 512k of non-TCM, is just not enough to store all of the samples at once that I need in order to do correlative calibration. Even at 8 bytes per sample (16 bit absolute value, 48 bit timestamp) I would only be able to hold a couple hundred samples per key.

On the other hand, the teensy is very capable as a "smart" ADC, timestamper, and data acquisition unit. There's a 480mbit USB HS 2.0 port right there, and I've set up flatbuffers via COBS encoding over the serial-style link I get over that. With "empty" message insertion, I should be able to avoid even the worst-case 1ms of latency from USB polling.

All of this means that the sound generator is going to need to be part of the system, and run some software. On the other hand, this means I can write the smarts in an environment with virtual memory, a normal allocator, multiple cores, 64 bit native word sizes, and can consume many whole megabytes of memory. This also means I'll be integrating a bar-style LCD panel for controlling it with a custom UI (probably written in Dioxus, I've been meaning to learn that) and however much number gathering/number crunching I want.

So, far from dead, but this gives me a chance to also re-spin the boards with component selection that isn't as fiddly to hand solder (those tiny analog switches were the bane of my existence), boards that fit into cheaper 10x10cm layouts, and sensor boards that have a more reasonable way to securely mount them. From an EE perspective this has been plenty robust, and I probably went a bit overkill on protecting signal integrity, so I can likely make things a bit more compact this time around.

Very excited to pick this back up and hopefully make a final push to get it done.