Velocity curves

[ajay_m]

If you want to get a general idea of the sort of processing involved to take raw sensor signals and convert to MIDI, there is a reaper plugin on the Reaper Stash (just google Qunexus Unleashed) which translates raw sensor data from the KMI Qunexus/KBoard products, transmitted as continuous CC values corresponding to key pressure (analogous in this case to your sensor position data).

From this data it then synthesises key velocity, pressure, modulation, pitch bend etc by performing a set of processing operations on the raw data such as normalising each sensor for range, and then after that it gets pretty gnarly but a lot of that stuff is to do the more advanced processing, particularly pitch bend, which got tricky (I had to actually numerically differentiate AND filter the data stream to get that working).

[but the end result is very satisfying; I have pretty much the expressive capabilities of the Osmose using these little keyboards, with pressure, modulation and pitch bend as independent control axes]

Because Reaper plugins are written in the JS programming language the plugin is its own source code, so you can see how the raw data was processed. This might give you a clearer idea of the sort of processing you might need to do in order to handle your sensors and the intrinsic variation between each sensor itself. On the Qunexus/Kboard the sensors can have as much as a 3:1 variation and the software equalises this so that the resulting velocity etc. sensitivity is consistent across keys.

[Wonks]

Given the above data, will this tend to make the velocity curve convex or concave?

Neither.

The velocity curves Martin gave you are for multiple keypress velocities being mapped to different output velocities (except for the linear 'curve' where you simply get a 1:1 mapping).



The input velocity on the X axis gets mapped to an output velocity up the Y axis.

So 50% velocity (MIDI value of 63) gets mapped to 50% output with a linear curve, about 80% (MIDI value of 101) with a convex curve, 100% (MIDI value of 127) with a saturated curve and about 20% (MIDI value of 26) with that concave curve.

Of course the curves can all be different shapes, there is no one convex or concave or saturated curve. Those are roughly the output values from the curves in those examples.

Your 'curve' produces a single velocity value. Its response is curved because that's the nature of the hall effect sensor affecting the sensor more the nearer the magnet is to the sensor. But it's still just being used to produce a single velocity value.



You are first going to calculate a 'velocity' from a given drop in value by the time taken to reach that value, or d/t. You would then scale that value so that the quickest velocity you can press at is a value of 127 and the slowest velocity you feel is right (as you could in theory take an infinite amount of time to fully depress the key, so you might want to limit it to say 1 second) has a value of 0.

Within the unit, you'd then map the velocity value to an output value determined by your selected velocity curve and output that value as part of the MIDI 'note on' information.

[Wonks]

And your sensors are (currently) all of the same type and won't have 3:1 variations in output levels etc. Hopefully they'll all have very similar output levels and you can use the same algorithm to calculate velocities and map the outputs of all the sensors.

But you do need to check the signal levels of all your sensors first to see if they are all very similar.

[BJG145]

OK, thanks for the clear explanation. I get that, but I was thinking of when you said:

If you want to calculate velocity by the time it takes to travel a fixed distance...you get a variable response time. Whether that lag on a slow push is enough to put timings off sufficiently to be noticeable you’ll have to determine yourself.

I'm not quite sure what you meant by that. But...you're saying that if the sensors are all consistent, then despite the curve in the output graph I'll get a linear response across different velocities...?

The velocity will be calculated and applied at the point the key reaches the end of its "logical travel", the lower threshold, though not the physical travel (because at that point, due to the nature of the keys and the sensors, the reading jumps back up to 255).

And that's OK, because on eg a piano, you don't get the note sounding until the key has reached the bottom. So I don't think there's a lag...?

Good point on the initial calibration; there's slight variation across the keys in resting position, though it might be small enough that I can ignore it. Worth bearing in mind though.

(I'm still not quite able to see intuitively whether I need to take readings at different known key velocities and see if the calculated MIDI velocities are linear, but if you tell me they will be, I'll take your word for it.)

[merlyn]

You seem to be getting a bit muddled with 'linear'. Linear describes a relationship between two things. There is a linear relationship between mass and weight -- it's simply multiplying by a constant. (y = mx + c).

Here, the relationship is between a time and a MIDI velocity. A piano doesn't respond to velocity as such. It responds to force (energy), and velocity (the time between the top and bottom of the key travel) is correlated with force.

In your setup, you measure a time (the shorter the time, the faster) and give that a MIDI velocity. It's up to you in the programming whether the relationship between time and MIDI velocity is linear.

[BJG145]

It's up to you in the programming whether the relationship between time and MIDI velocity is linear.

Right - I was just wondering if it was inherently skewed by the distance/output response curve on the hall-effect keys. But it sounds like it's not. (?)

Perhaps one way I could understand it would be by considering one of these.



It might be a twisty path, but if you traverse it at twice the speed you're still going to do it in half the time.

[Wonks]

OK, thanks for the clear explanation. I get that, but I was thinking of when you said:

If you want to calculate velocity by the time it takes to travel a fixed distance...you get a variable response time. Whether that lag on a slow push is enough to put timings off sufficiently to be noticeable you’ll have to determine yourself.

I'm not quite sure what you meant by that. But...you're saying that if the sensors are all consistent, then despite the curve in the output graph I'll get a linear response across different velocities...?

Not really.

Hopefully we've determined that the signal strength from the Hall Effect sensor is related to the amount the key has been pressed down. And that it's not quite a linear response, it's a slight curve.

If we consider the time it takes for the signal to drop from a value of 200 to 100, then the faster the key is pressed, the shorter that time is.

So we have two variables: the change in signal level and the time taken for the signal level to drop a certain amount.

As I've said before, there are two basic velocity detection methods we can use.

1) We fix the signal level drop we want and measure the time it takes to drop that far.

The faster the velocity, the less time it takes for the signal to drop that far.

The slower the velocity, the longer it takes for the signal to drop that far.

2) We fix the time period we measure the signal drop in and measure how far the signal drops during that time period.

The faster the velocity, the further the signal level will have fallen in that time period.

The slower the velocity, the less the signal will have fallen in that time period.

.....

Hopefully you can see that with method 1), the slower the velocity, the longer the time we need to wait before we can determine the velocity. And we can't send out a note without a velocity value.

So say at our fastest velocity, the signal has dropped from 200 to 100 in 0.5ms. That's nice and quick and we can send out our 'note on' MIDI message almost immediately. You won't notice a 0.5ms delay.

But at a medium velocity, it might take 10ms to drop from 200 to 100, so we cant send out our MIDI message until after 10ms has passed since the key started being pressed. That's getting quite laggy.

And at a really slow velocity it might take 100ms to drop from 200 to 100, so we cant send out our MIDI message until after 100ms has passed since the key started being pressed, and that's really laggy.

That's what I mean about a variable response time.

So I prefer method 1) where you pick a fixed measurement time and work out how far the signal level has fallen in that period.

You could pick say 3ms as an acceptable lag to allow for a measurable drop in signal level. 1ms or 0.5ms might be fine. You're the one with the test results so you should know what the timings are like.

But to do this well, your signal level measurements need a high degree of resolution. If you can only measure in steps of 4 units, you're OK with the big drops, but as the drops get smaller in that time period as the velocities decrease, your calculations for the velocities get less and less precise and you end up with big jumps in the calculated values.

A drop of 100 in a 1ms time frame is reasonably accurate, even if you can only resolve down to 4 units, but a drop of around 5 units in 1ms might read as 4 units or 8 units, depending on the exact voltage. And that can give you quite a different velocity.

Again, you know what sort of resolution you're getting on the signal levels, which is why you may need to match the signal voltage to the maximum A/D input voltage to maximise the resolution. If you can measure in 0.5 unit steps, then that's probably good enough, and 0.1 is fine.

But if you are happy with the note on info not being sent out until the bottom of the key press (remember it's not a piano keyboard) then method 1) is probably easier to implement. You just need to set a maximum keypress time to get a workable minimum velocity figure.

[merlyn]

No, because if you think about it, on the simple make/break switch you posted above, absolutely nothing is happening between breaking and making, and that makes absolutely no difference.

It's only the time you want.

EDIT : Yes, that twisty buzzer puzzle has a convoluted path, but it makes no difference to the time taken to complete it.

[BJG145]

Hopefully you can see that with method 1), the slower the velocity, the longer the time we need to wait before we can determine the velocity. And we can't send out a note without a velocity value.

Couldn't you say the same about any keyboard instrument though? It takes longer to sound a note from the beginning of the press to the end of the travel if you press it slowly. But people don't expect the note to play until the end of the travel.

I take your point; people might expect the "activation point" on keyboards to be higher. But for a velocity-sensitive MIDI keyboard instrument I think this is OK. So, I'm happy with that.

[Wonks]

Hopefully you can see that with method 1), the slower the velocity, the longer the time we need to wait before we can determine the velocity. And we can't send out a note without a velocity value.

Couldn't you say the same about a piano though? It takes longer to sound a note from the beginning of the press to the end of the travel if you press it slowly. But people don't expect the note to play until the end of the travel.

As I said in my edited version, it's up to you when you want the note to be sent out. A piezo-driven drum pad will output almost immediately as its working directly on the voltage level generated by the force of the hit. You'd struggle to get a quiet rhythm pattern going (especially if interspersed with louder hits) if you had a lot of lag between hitting the pad and hearing the sound.

But it's not a piano keyboard (at the moment anyway), so for others (especially non piano players) it might take them aback to find they have to press the key all the way down before they get a note when playing quietly.

It's your controller, you decide how you want it to behave. I'm just trying to give enough information for you to make informed decisions.

[BJG145]

You have, and I thank you.

(I'm reinventing the long-lost Axis-49.)

https://www.soundonsound.com/reviews/c- ... ic-axis-49

[Wonks]

Note the requested ability in that article to turn off the velocity feature. You could just default to 127, or a software adjustable value, or even switch to a slider for setting the required default velocity level.

[BJG145]

Note the requested ability in that article to turn off the velocity feature. You could just default to 127, or a software adjustable value, or even switch to a slider for setting the required default velocity level.

Good spot.

(Full-size PCB due in a couple of days. Did I hear you volunteer for beta-testing?)

[Wonks]

If you get it assembled sometime before the end of next week I could prod a few buttons.

[BJG145]

Just found these in the shed, fresh from China.

My PCB habit is becoming rather expensive.

Nothing ventured, nothing gained. I'm not letting James' kid's mechanical prodder anywhere near them though!

[Jimmy B]

First, I agree with all of the above.

I'm not primarily a keyboard player, so please feel free to shoot down the following random musings.

It seems to me that pianos behave how they do, not because that is ideal, but because because 300 years ago someone tried to make a harpsichord that had variable output level, and that was the best that they could come up with, given the best wood-working technology of the time.

Looking at my upright piano, it has:
-variable key resistance as the key descends
-inertia due to the mass of the hammers and associated mechanism
-hammer velocity that should be an integral of the acceleration of the key over the time for which it is applied. A short stab on a key for less than the full key travel would accelerate it to (approximately) the same velocity as a longer, slower press.
-an output level that is some function (not necessarily linear) of the hammer velocity
-some level of latency while the various mechanical parts move and the strings start to vibrate.

It seems to me that given sufficient computing power and a sensor that knows exactly where the key is (such as this magnetic one), and a suitable solenoid to simulate resistance and inertia, it should be possible to emulate a mechanical piano keyboard pretty exactly. It should also be possible to create a different behaviour, which would be impossible using woodworking technology. For example, we could have a very light or heavy touch, high or low effective mass, different varieties of after touch, etc. Of course, midi signalling might not be adequate to carry this information, and we might need to invent a different protocol, as someone has implied above.

Does all of this make sense? Would it have any value?

[BJG145]

...after many late-night arguments with ChatGPT, it's gradually getting there...

https://youtu.be/3PWE7woWvRw

(Harmonic Table)

[Wonks]

Great!