Another DIY hybrid

RIP

I did! Honestly I would probably be quite a bit further along by now if I'd just followed one of y'alls' guides instead of trying to roll my own--I landed on some of the same decisions anyway. I was initially going to do a double switch (morphed into optical interrupters) but I realized that would have really finicky calibration so I went down the continuous sensor + ADC route. I settled on hall effect sensors though, since initial tests with the Allegro A1302 actually gave a very clean and wide ranged signal with no amplification and no extra power filtering with the Teensy 4.1 internal ADCs. That gave me (rough estimates incoming) about 250 distinct levels at 10 bits, with about 1 bit of noise sampling at ~800ksps. Doing a linear regression across the samples I'm sure also gives me much improved precision, assuming gaussian noise. The sensors also have less than 2 or 3 parts in a hundred of cross talk vs signal, which I can cancel out with a simple linear compensation function as a compute kernel.

I'm probably going to go with a DRV5057, get a sample of their different sensitivities and get the one that most nicely maps the field strength range I get to a 0-3.3v signal. The sensors have built in amplification and some level of power filtering, plus temperature compensation and such. They also are very resistant to interference IME, at least compared to optical sensors.

I'm doing my best to avoid doing any actual electrical engineering since the best math I can do is competitive with the worst Fermi estimates, so I shouldn't be trusted anywhere near problems like "how do I not burn out an LED" or "how do I tune an op-amp". The hall effect sensors gave me a very self-contained solution that I just need to put hot to hot, ground to ground, and I magically get a signal out the other end that works fine with ultra-high-impedance sinks. The approach so far has been to just use the fact the Teensy has a stupidly fast CPU to work software magic to correct for any weirdness that the hardware may display (nonlinearity, different offsets, noise, that kind of thing)

sawyer bergeron I'm probably going to go with a DRV5057

If you open source HW the sensors I will likely try them with my piano. For fun.

The piano I built works with a wide range of sensors. And, I recently added a snap-on interposer board to make the system even more flexible. So shouldn't be too difficult to try.

sawyer bergeron was wondering what y'all have tried for striker rail materials.

I've studied several materials from very soft to hitting the metal bar direct.

stem piano streams all raw measurements over Ethernet. It is easy to load and analyze the data with Python. I've found that all materials introduce oscillations in the frame (as @CyberGene mentioned) and shank which can couple into the sensors and reduce accuracy. Also, the softer material can reduce velocity accuracy, depending on the algorithm. I presently use firm foam about 6mm thick. It does not deform much on strike, according to the streamed measurements.

Dean I'm curious about how the touch of a DIY MIDI

Its better than my other digitals by a huge margin. Not even close.

sawyer bergeron Have you had any pros try to regulate your action too?

I had the piano action professionally regulated to the frame I made.

General comment - firmware is biggest project time. At ~4000 lines of code. Furthermore, since open sourcing a fully working and tested piano on GitHub last November….. I have discovered and opened 60 issues (and closed 45). History is on GitHub

gzpiano absolutely open sourcing this all, though it's bespoke--doesnt use stem piano arch, and has custom PCBs that multiplex analog to a single teensy (reuses the same board, has bridges for converting between host/pure sampler board).

The code for it has actually been the most fun part for me 😛. Teensyduino is a joy to use after doing VAX assembly and emulator dev for my day job so it was nice to escape into that for a while. I tried using baremetal rust and threw my hands up in dispair after not too long--it just didn't feel ready, the HAL for the teensy is broken and the deps out of date in too many ways for me to just forge ahead at the moment.

gzpiano I've found that all materials introduce oscillations in the frame

I still don't understand why you guys insist on using cheap, and not properly engineered, hardware-store-grade extrusions 😛 when much better ones such as the ones sold by Misumi are available and not cost prohibitive. These other options make also assembly a breeze, with no drilling and no fear of mistaken placements (since it can all be easily adjusted).

On the other hand, as a physicist, I must agree that a hammer hitting a bar of any shape and material will introduce oscillations. The best one can do is to be in a very careful range of damping, where they get dissipated in about a wavelength. However that is tricky for various reasons too long for this margin. The second best one can do is making sure that the vibrations will have an amplitude much less than one cares.

I have not measured such amplitude for my setup, but I have made several worse-case computation of those, and I've concluded that (with my extrusion) they should be well under 0.1mm of excursion. I'm looking forward to do the measurement as soon as I am able to assemble some additional electronics, using the method that @gzpiano has nicely designed and implemented.

gzpiano I recently added a snap-on interposer board to make the system even more flexible.

🎉

gzpiano History is on GitHub

Yes, I've already nudged @sawyer bergeron to go there and look, as I'm doing myself (as you well know since I often nag you on those open issues 🤣 )

sawyer bergeron absolutely open sourcing this all, though it's bespoke--doesnt use stem piano arch, and has custom PCBs that multiplex analog to a single teensy

He said you should open source the hw design, not use stem_piano architecture or PCBs. Just publish the schematics 🙂 -- even though if I understand correctly those sensors are very simple and there's nothing other than attaching them straight to the ADC input? How about voltage range and impedance? Do the sensors miraculously match the ADC as long as you power them with the same voltage?

If you have too much damping and hammer doesn't rebound as much as in real piano, you may have some problems with fast repetition while palying softly, hammer will not go into check and action may behave weirdly and you may get double striking etc… It may not matter for you if you don't play music requiring that. Also you definitely do not want hammer checking to be much noticeable at the key, it would mean that your backchecks are not regulated properly and hammer hits them instead of wedging into them.

I don't want to offend anyone, but I often encounter a strange desire to reproduce inherent flaws and flaws caused by improper regulation and/or wear of real piano actions, which probably stems from unawarness how it should work in a good piano and taking old worn out pianos as a reference.

RIP the reference circuit in the datasheet for them was actually just "run the output directly to your ADC", not that I hadn't already done that anyway before checking 😅. I looked at stem piano and there was a lot of EE stuff that went over my head at the time, so I was hesitant to blindly follow instead of working it out myself. The sensors just match the onboards ADCs it seems, and IIRC the "ratiometric" part of their name was about how their output voltage will be relative to both the voltage on VIn and the field strength, so it's probably less surprising/magical to the designers of those things that it "just works" how I used them.

ambrozy maybe I'm just used to old pianos then haha--I'm not trying to make a "clinical" feel, just one that feels "natural" and fun to me, even if that means technically a "worse" feel at a technical level. I'm playing for an audience of one, so it's not like I owe "perfect" to anyone but myself

Anyway it should always be better to at least try to go in the "perfect" direction even if you are not requiring "perfect", because otherwise you sort of asking for a problems, what action you working on?

ambrozy If you have too much damping and hammer doesn't rebound as much as in real piano, you may have some problems with fast repetition while palying softly

I agree with you and FWIW that was one part of my "too long for this margin" 😉

sawyer bergeron run the output directly to your ADC

Awesome. Interesting approach of using frequency (rather than amplitude) to sense position. However I don't understand exactly your resolution plan. According to https://www.digikey.com/en/product-highlight/t/texas-instruments/drv5057-digital-pwm-output-hall-effect-sensor the "rest" output is 2kHz. That will quickly get multiplied (potentially by a lot) once you start multiplexing and/or sampling at high frequency to get more resolution. Even so, you will need several measurements (to identify current frequency) just to get one position, as opposed to a single measurement for a single position. That seems a bit complicated. Am I getting anything wrong? Have you written already the code to do that?

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.