Scanning speed and velocity mapping of Cybrid

JayKominek I think I'm still holding out some hope that per the discussion at https://github.com/jkominek/piano-conversion/discussions/31 the fact that the ADC has some spatial resolution might save us from needing all of the temporal resolution you're suggesting we need. But, would have to think about it.

Yes, I think there is some hope, but thinking about it more explicitly is better, hence all the "noise" that I started on this topic. If I find time to stop monitoring the forum and do some soldering (and solve a couple of RPI Pico sw issue), I may have a 9-note MIDI-complete prototype (*) to install in my action in a couple of days. And that could provide some hard data to discuss.

(*): with the 'CA6 sensors. I could order more QRE1113 (I have only one) and/or CNY70 (I have only three) if needed

In case it is helpful, I put some data here along with short Matlab code to demo/explain.

https://github.com/gzweigle/DIY-Grand-Digital-Piano

And, .. nice forum.

CyberGene Now, as I said things were not that simple 🙂 I noticed that with just using that static formula the higher notes would produce unnaturally high velocities. I gave it some thought and finally concluded that that the higher you go, the less heavy the hammer is (at least in my action) and thus it's easier to throw it with a high velocity. However it's also lighter, so the higher velocity is negated by the lower hammer mass (and shorter strings) to produce balanced tone which is why it turned out I had to compensate on a per key basis

That's a flaw in the VST intended to be used with weightless identical keys over the entire range. You shouldn't have to compensate for that in the controller.

Deleted Yes, you're absolutely right. It's just how Garritan CFX is made because that's what I used for my calibrations. They have mapped velocity and timbre curve of its response to not account for the heightened velocities of the smaller treble hammers as on real pianos. It seems all virtual pianos are programmed that way though.

CyberGene The VST audience is not expected to actually play the piano (or be able to). So the plugins are tailored to react to MIDI messages in a predictable way. Any compensation is up to DAW MIDI filters.

My old Kawai ES100 didn't actually compensate for the graded hammer weights in the MIDI controller. Instead the built-in samples were somewhat (over)compensated, leaving the remainder of the compensation to the pianist (who is expected to be able to). I wonder if the samples are still the same after they replaced the action in ES110 with a cheaper GHS-tier one with a much shorter pivot, making the effect much less pronounced. Or if the treble is now just dull.

Just learned about Cybrid yesterday and joined in here to chime in. Very impressed with what I've seen so far! I have some thoughts I wanted to share - more than I really have time for ATM, but we'll see how far I get.

First, discussion of hammer speed is something of a proxy, as I don't know of anything aside from the alpha piano that even measures based on the hammer. The "hammer" sensors I'm aware of are at the shank, or rather the flange. These move much slower than the hammer itself, and on the same order as the key, so in a certain sense, numbers for the velocity measurement end up quite similar to doing key-based sensing.

For relating actual velocity to something we see electrically, time to pass a defined distance of course gives us that. For "digital" sensors like the shutters used in the Kawaii ATX and NV, the distance is defined by the spacings of the shutter edges relative to the sensors, and resolution is limited by the rate at which you can sample the sensors. I recall reading, possibly in the ATX service manual, that Kawaii uses a 110kHz sampling rate, but without knowing the actual distance between sensors being measured, that number alone doesn't tell us that much. I do doubt that the measurement is limited to the few mm of hammer position between let-off and hammer strike.

With an analog sensor like the CNY70, we can of course fake the digital sensing approach with two comparators. Now the accuracy isn't limited just by the sampling rate, but it's also affected by the precision to which you can set the comparator thresholds. With the multiturn trim pots, this probably isn't too bad, but with a 8-bit ADC and soft-defined thresholds, the resolution of said thresholds is probably significant.

But using a multi-bit ADC only to compare against a few thresholds is throwing away information the ADC is conveying, and if we're then concerned about limits of resolution of what's left, well, to me that feels like throwing the baby out with the bathwater.

With ADC output available, just taking the difference between subsequent ADC output samples gives you a value for velocity. There are of course resolution limits, but the fact the velocity is continuous and won't change arbitrarily from one sample to the next lets you also filter that result to take advantage of prior samples too for a better estimate. Better yet, as you're watching the velocity from sample to sample, it's possible to detect when there's a sudden change and I would want to use the peak velocity before this change for the measurement.

Of course this is more computation for the controller to do, and the controller talking to the ADC needs to happen with a regular clock that doesn't vary with the controller's load. On the other hand, this should relax the sampling rate requirement, too. Hard to say which side wins.

Even if we wanted to stick to a 'comparator' based approach, we can do better by making use of the ADC output. If one sample is just below your threshold and the next one well past it, that's a different scenario from one sample being far below the threshold, and the next one just crossing it. In a sense, you can interpolate between ADC samples and find where you threshold lies between sampling instants. Again, this should allow relaxing the sampling rate, but at the expense of needing more computation. The interpolation actually requires a division but on the other hand, this only needs to be done twice per key event rather than every sample of every key.

luns The "hammer" sensors I'm aware of are at the shank, or rather the flange. These move much slower than the hammer itself, and on the same order as the key, so in a certain sense, numbers for the velocity measurement end up quite similar to doing key-based sensing.

Hi and welcome 🙂

It doesn’t matter where the sensors are because I’m measuring the duration between two sensor activations and those two points are set based on where the actual hammer tip is, the first point 2mm before stop rail and the second point at stop rail. So, I know that the actual tip of the hammer traveled 2mm for a certain time and that’s the real velocity I’m measuring and using. Sure, the linear velocity of the shank where the optical sensors are, is lower than the tip of the hammer but even if I measured it, it wouldn’t matter because I would be measuring the same duration. I would use a shorter distance which would lead to lower velocity but even in that case it wouldn’t matter since it’s the relative velocity that matters and needs to be mapped into a range of 0-127.

But other than that I agree with you about the resolution and the waste of an ADC if used to simulate what the trimpots and the comparators do in my solution.

luns Just learned about Cybrid yesterday and joined in here to chime in.

Welcome to the clack, or rather I should say welcome to the clique 🤣

Have you seen the whole (still incomplete) series of my posts, haven't you? https://pianoclack.com/forum/d/163-build-your-own-hybrid-piano-step-one-choosing-the-action -- I think somewhere I partially answered your concern/objection regarding sensing hammers vs shanks, which obviously for the ADC approach matters, unlike the comparators approach as CyberGene has just described. I think having the sensors in either place is fine, but I prefer to work with the hammers, so it's easier from an acoustic action regulation and understanding (among other things). If and when the requested speed of the ADC proves to be unfeasible or too expensive, I'll move to another approach. Being DIY, everyone is free to purse the project the way they see fit, obviously.

luns But using a multi-bit ADC only to compare against a few thresholds is throwing away information the ADC is conveying, and if we're then concerned about limits of resolution of what's left, well, to me that feels like throwing the baby out with the bathwater.

luns Even if we wanted to stick to a 'comparator' based approach, we can do better by making use of the ADC output. If one sample is just below your threshold and the next one well past it, that's a different scenario from one sample being far below the threshold, and the next one just crossing it. In a sense, you can interpolate between ADC samples and find where you threshold lies between sampling instants. Again, this should allow relaxing the sampling rate, but at the expense of needing more computation. The interpolation actually requires a division but on the other hand, this only needs to be done twice per key event rather than every sample of every key.

That is exactly why I think for this project the ADC is a better approach than comparators (with potentiometers or with DAC). In fact, I (eventually) plan to do something like what you describe. However, one has to start somewhere, and hence I'm starting with the very crude algorithm which does simply three comparisons (as if it were three physical switches) and ignores everything else. To reiterate just to start somewhere not as the ending point. I hope to have something to share after the weekend (crude, but working, hw and sw prototype)

For my DIY hybrid version, it continuously computes the velocity with an FIR digital filter (in a microprocessor).  See line 56 of Matlab code in linked github page above.  When I play the piano, it sounds great…..although….. only 8 keys assembled…. no la campanella….

gzpiano For my DIY hybrid version, it continuously computes the velocity with an FIR digital filter

Do you mean this line

dx = filter(b,[1],samples) * 2 * 0.0254 * sample_rate / (M+2);

Where is filter defined? Is it intrinsic matlab function?

Edit: Please ignore the dollar signs above. If you are curious they were supposed to make the above line "look like a formula", but they don't work. The dollars gave me gripe when using them as money unit, continue to give me gripe when using them as function / code delimiters. They are displayed normally in the text, but they are untouchable in edit mode: once you mistakenly type them (as I did) you can never delete them (try if you don't believe me)

RIP I fixed it for you but you need to use backticks, not dollar signs.

luns The "hammer" sensors I'm aware of are at the shank, or rather the flange. [...]

luns I do doubt that the measurement is limited to the few mm of hammer position between let-off and hammer strike.

Looking at the ATX service manual...

1) Let-off is set at 4mm (page 10). Possibly slightly wider than a pure acoustic action to accommodate the stop rail? To make the sensing easier?

2) Taking measurements from figure 4 (page 4) suggests the measurement is taken over a hammer movement of about 3mm, although the shutter on the flange is only moving around half this distance due to its location. The figure may well not be to scale but it is clear anyway from the shape of the shutter that the distance measured is very small.

3) From the section on adjusting the sensor height (page 12):

For instances, if the sensor is located at an extremely high position, the position of emitting sound may be higher than the position where the hammer stops by the stop rail. In this state, no electronic sound will be emitted.
On the contrary, if the sensor is located too low, this may cause deterioration of the functionality in detecting consecutive key stroking.

So... "too high" = past the stop rail, "too low" = repetition stops working i.e. below the let-off, so it seems that "just right" is indeed limited to the few mm of hammer position between let-off and hammer strike.

gzpiano , it continuously computes the velocity with an FIR digital filter (in a microprocessor).

FIR filtering... Clever idea. But using unsupervised realtime FIR filtering, are you able to separate a low velocity hit from a low velocity silent note (ie, the hammer is slowly advanced to 1-2mm of the string and does not touch it because of the jeck slipping under the knuckle? And can you compute strikes that have 2 velocities (ie, slow advance until let off point and the sudden acceleration?). My basic knowledge of FIR makes me think it is good for linear movements not complex "multipeak" so to say... Am I wrong? (most probably because I am above my paygrade here 😊). Asking this because FIR may be an interesting approach to realtime analysis of my non-music related professional data signals, but I never attempted to use it, and maybe I should...

RIP Where is filter defined? Is it intrinsic matlab function?

Per @gzpiano post I assume the FIR is computed in the microprocessor and the result fed to matlab.

vagfilm delvento Where is filter defined? Is it intrinsic matlab function?

Per @stem_piano post I assume the FIR is computed in the microprocessor and the result fed to matlab.

Perhaps, but the matlab code has a filter function call which is not defined in the provided source, so I wonder what that is.

RIP

Yeah, filter() is a Matlab function. Its just a convolution (denominator is set to [1] on line 56). You should be able to run this code with Octave as well, which is free open source. The hammer position sample data is provided in the same directory.

If anyone wants to go this route, its fairly easy to find DSP libraries that implement the taps on line 41. Those taps include a lowpass filter to reduce some of the differentiation noise.

Although I am happily building my worlds-most-unnecessarily-complicated-DIY-hybrid, I am also happy to help out other projects, for example providing a filter implementation pull request. However, I can't guarantee any schedule or deadlines.

vagfilm

Yes for sure, there needs to be more to the algorithm. FIR is just the subset for a continuous velocity calculation.

gzpiano FIR is just the subset for a continuous velocity calculation.

Thanks and "too bad"... It would be neat for my other things... But I may give it a spin since I never played with FIR filtering.

gzpiano For my DIY hybrid version, it continuously computes the velocity with an FIR digital filter (in a microprocessor).  See line 56 of Matlab code in linked github page above.

Any opinions on alternative filter constructions? I was fiddling with Savitzky-Golay on some old recorded data last night, getting decent looking results, and was thinking about trying to squish it into my firmware this afternoon.

JayKominek

Good idea. I convolved a boxcar (moving average, [1 1 1 1 1… 1]) with a first order numerical derivative [1 -1] to get the taps in that code on github. Rather simple. Where I have seen noise most problematic is in low velocity hammer strikes. Super quiet notes. Savitzky–Golay might be a great way to get better accuracy for that case.

The github data is relatively fast strikes, so it doesn't show the noise issue as much.

gzpiano Any chance you could post some of the low velocity strike data? I've been messing around with the strike data that's on GitHub (and may post something about that soon) but if there's some more problematic data it would be good to see it.

Also, how constrained are you for processing power? Are you doing boxcar + first order just to try the simple stuff first or are you needing to avoid multiplications and divisions?