Another DIY hybrid

ambrozy I'm probably setting myself up for a rough time by that metric then--I found a Aeolian era Weber. Has nice ivory keytops, and the wood is in decent condition, but the felt has definitely had a longer and harder life than it should be expected to. I expect rebushing/refelting is going to be a labor of love for the next while even once I get it working as a midi controller. If things absolutely go to ****, I can always bug a piano technician friend to smuggle me a WNG top action for enough $$$ and have something that's starting out in good shape. Still need to rebush the keys, but don't want to just toss the nice ivory tops they have on them so I'm keeping those.

RIP ah, I hadn't checked the DRV5057 in depth, I've been using Allegro A1302 for my prototype so far. I'm sampling both position and time for each, and using a linear regression on the (distance, time) samples to get a derivative. Could probably use additional statistical measures to reject outliers, but as-is with my attention model on a prototype "toy" action it's almost impossible to get a hit with fewer than 30 samples even without using attention, and the regression is robust enough against noise at that point anyway to not have to do averaging of multiple samples per "sample".

Using attention was also the big add--lets me avoid sampling keys most of the time, and only frequently sample the few keys that are being actively pressed (at a higher frequency than I could all of the keys together)

sawyer bergeron

You are going into a rabbit hole my friend

RIP ah, I goofed, meant the DRV5056 😅

ambrozy That pretty accurately describes the last few months for me lol

RIP as a physicist, I must agree that a hammer hitting a bar of any shape and material will introduce oscillations

I have a physics question….. (maybe this is for a different discussion?)

Been able to identify the physical source of all oscillations except one.

It is an approximately 3.5 millisecond period, very small amplitude oscillation.

Starts almost immediately upon hammer strike, decays slowly, and lasts about 100 milliseconds.

It appears to be in the hammer shank only, not the frame or sensors. Could it be an oscillation in the wood of shank?

sawyer bergeron ah, I hadn't checked the DRV5057 in depth, I've been using Allegro A1302 for my prototype so far.

sawyer bergeron ah, I goofed, meant the DRV5056

Ah, that makes sense, then it's similar principle to optical sensors. https://www.digikey.com/en/product-highlight/t/texas-instruments/drv5056-ratiometric-unipolar-hall-effect-sensors

sawyer bergeron Using attention was also the big add

??? Are you doing deep neural networks for this???

I like the name of thread and for next DIY we should call the discussion "yet another"… 🙂

hammer shanks vibrates in audible range after strike, thats normal, but sometimes can be annoying

RIP oh no, not at all 😅 attention as in I can sample keys at maybe 700hz when they are completely unpressed, and as soon as they go down by more than a small threshold I switch to polling them "as fast as possible" to get higher resolution on keys that are actively being pressed and ignore the 60+ other keys that aren't even being touched. I have the code and very WIP schematics up at https://github.com/szbergeron/hybrid_piano

gzpiano I mean I have been looking for a name for this thing…

gzpiano Been able to identify the physical source of all oscillations except one.

That's a big question, which we can definitely tackle. Answering the beginning here not to keep others in the dark, but perhaps it's best taken into its own conversation (or github issue or maybe even privately via email)

So when you have a complex body oscillating you excites a number of things. Consider a weight attached to a rope, it can move left-to-right and front to back (assuming the rope stays always taut). It will move left-to-right if you initially excite it in that direction and likewise in the other direction. In this case, the two physically and geometrically meaningful "things" stay separate. In more complicate cases (such as a piano string in a real piano) they mix up. You get a small glimpse of this at https://en.wikipedia.org/wiki/Normal_mode

In addition to the ones which you certainly are thinking about, there will be torsional ones such as these: https://www.acs.psu.edu/drussell/Demos/Torsional/torsional.html

I'm sure this does not answer your question yet, but it does give you more information in theory, and in practice it explains the need to use more than one sensor to gather information about what this might be.

sawyer bergeron I mean I have been looking for a name for this thing…

how about sybrid or sawybrid ? By the way, we should pull in @xooorx who's also plans to use similar sensors as described at https://pianoclack.com/forum/d/238-another-diy-controller-project (so yes, this should have been "yet another" in the thread title)

sawyer bergeron and as soon as they go down by more than a small threshold I switch to polling them "as fast as possible" to get higher resolution on keys that are actively being pressed and ignore the 60+ other keys that aren't even being touched

Good idea, I also discussed something like that in stem_piano on github, but only for dampers, not keys.
If you are doing it for keys, how do you guarantee that if another key does get pressed while the first is being "attention-sampled" you don't miss it?
I mean for dampers it's obvious: if the key hasn't been pressed, there is no point to sample the damper (duh!) -- but if I press one key I don't want all of the sudden the rest of my keypresses become slow-responding (think about chords, and chord voicing)

RIP my main sample loop in that repo has the functionality (on mobile so not digging through for line number at the moment), it comes down to scheduling priority and which keys are "due" for sampling in the current "round". Let's you use a single teensy across 88 keys but know that it'll only ever need to be "paying close attention" to maybe 15 at most with real playing, with graceful (quieter presses) if it ever manages to get overwhelmed

RIP the code in question: https://github.com/szbergeron/hybrid_piano/blob/main/sampler/src/main.cpp#L557 and https://github.com/szbergeron/hybrid_piano/blob/main/sampler/src/main.cpp#L758

It's interspersed with logic to optimally saturate both ADCs on the Teensy since not all of the analog pins are muxed to both of them. I was going to see if I can cram coroutines in there (or manually lower some async logic) to continue doing note processing while waiting on each sample, just to keep the ADCs "fed" with requests a bit better. The CPU is waiting around doing a whole lot of nothing most of the time anyway, so any time the ADCs are waiting on the CPU is time arguably wasted. If I'm still seeing note variation from lack of sample density, I have the board set up so I can add additional teensys to break up the daisy chains down to as little as one board each.

@sawyer bergeron Just to clarify, because I am bit lost (as usual… 😀) : you are only measuring key travel, correct? No hammer detection… And where are you placing the sensors? On the keys or in the keybed? With an external magnet or metal piece?

Many moons ago I toyed with a fixed hall sensor below the keys and a small magnet on the underside of the key, and gave up because I had a lot of crosstalk from the neighboring keys. This means that I chose the wrong design or the wrong sensor 😀...

vagfilm I'm measuring hammers, sensors are going to be mounted on a rail above them, with magnets on the shanks. I did a test with a Lego model while I was getting my salvage action, and did find there to be some crosstalk, but I can do a relatively simple transformation to "de-convolve" the gaussian to reduce it from the 10 parts in a hundred down to likely sub-0.5 compared to the direct signal from the matching hammer. Basically, take the measured value from neighboring keys (to some reasonable kernel size) and subtract some offset as calculated by some mapping function. You can do that once for a significant reduction, out to n times (with scaled down contributions each time) in a long tail of diminishing returns. The (observed, but not scientifically measured) low noise I'm seeing from the sensor is really exciting to me, since it means even if I have to do some corrections I'm at least not going to be forced into wasting a bunch of measurements just filtering out noise.

I'm definitely winging this a bit, I've never been much of a person for the controlled rigor of science (let alone writing it all down…) but so far everything has been quite straightforward and had pretty obvious choices just from looking at the outputs.

Thanks. I assumed you were measuring key travel and not hammers because you mentioned something like using early movement to assign faster sampling. Somehow that sounded more appropriate to keys than to hammers. Very nice project…

Finally got my action in, and realized I was naively optimistic in my hope that the hammers would be evenly spaced save for the gaps between each bank of hammers. Having separate sensor boards from controller boards was probably the way to go all along. Initial tests (with legos, some tape, and a spare set of hands to hold things in place) indicate that I way overspec'd my software, and piano hammers don't move as fast as I assumed they could in the worst case scenario. That does give me some extra headroom for adding an extra control board with some slide potentiometers on it as a midi control surface though 😃

Going to try a bit of an experiment for mounting the sensor rail: I've found threaded rods that match the threading for the screws that hold the hammer rail to the top action, which are the same as the ones that hold the whippen rail to the brackets. Hopefully, I can attach the striker rail to the rear rail (with some rubber washers for damping) and the sensor rail to the ones extending from the hammer rail. If having the striker rail coupled even that much to the top action causes too much vibration then I might have to redesign my cabinet a bit, but I'm cautiously optimistic that it'll work

I figure the more tightly I can couple the sensor rail to the hammer rail at least, the better my readings will be even in the presence of vibration (it would require rotational vibration to see any significant disruption, not just translational)