Velocity curves

[BJG145]

* spoiler alert, bit of a ramble *

Some stuff that you take for granted as a performing musician is pretty complicated when you look under the bonnet. Like velocity curves.

I've been experimenting with generating Midi velocity from hall-effect sensors. (One of the Gullsonix boards.) It's getting there.

https://www.youtube.com/shorts/EkHxVErlW2Q

It works. But I'm trying to get to grips with velocity response.

One common approach to creating a velocity-sensitive keyboard is to create a mechanism whereby pressing a key operates two contacts consecutively. By looking at the time difference, you can figure out how fast the key was travelling.

I can't find any pics just now, but from pulling apart an assortment of synths I seem to remember that break-before-make is a common approach. As you press a key, a contact is broken. As you continue to press, another contact is made. On springy metal tine things.

Creating these mechanisms from scratch is difficult. You can find keys that have this mechanism built-in, but they're mainly a bit rubbish...I've never found one suitable for playing on. They also have names like "SPDT" (single-pole, double-throw).



You get the idea. But the reality is, you end up with something like this.



Very stiff, short travel.

*****************************

Another approach is to use analogue keys...like, hall-effect keys. You have a key which is basically a magnet on a spring...



...placed above a hall-effect sensor, which returns a continuous range of values as the magnet looms near. You can define two thresholds corresponding to the break/make contacts, and you're in business.

Then you have to deal with the response curves.

I've been experimenting with Lekker L45s paired with the OH49E-S, which isn't a bad combo (vid above), and wondering how to finesse the velocity response. I started by logging all the values as the key passed between two points, and considering the graphs.







The first thing you will notice is that these are not linear.

Each graph basically shows the output from the hall-effect sensor as the key is pressed. The non-linearity is a combination of the electronic properties of the sensor (proximity of magnet to sensor not necessarily having a linear relationship to output) and the the mechanics of the press (clumsy human stabbing a plastic key will result in some complex acceleration/deceleration etc).

The second thing you will notice is that the curves are not equal. The curviness changes at different physical velocities.

If we wanted to create a linear velocity response, how do we do that...? I don't think the curve of the particular presses is such an issue here...I think it's more a question of considering the change of curve between different velocities.

I think you'd probably want to start by making the number of samples in the data for each of the three curves equal - because they ain't. The nature of the sampling method (logging the values with an Arduino) means that you'll collect more samples for a slower press than a fast one. To make the lists of sample data equal length, you'd need to apply a best-fit-graph, then interpolate. All easily done with Excel of course. Providing you know Excel, and understand trendlines, or whatever.

Then you'd need to create a kind of curve of curves; you need to examine the nature of the change in the curve at different velocities. You'd take the ubercurve (yes, I'm making up the terminology as I go) and figure out a transformation to make it linear - or at least, I think so.

(I was hopeless at maths at school. I still remember the ignominy, if inevitability, of being demoted to the bottom set. I'm more interested in it now but I'm still no good at it.)

But...that's assuming you even want linear velocity response. And you might not.

At this point I Googled it and found a SOS article by Martin Walker, which was a flickering candlelight in the mental darkness.

https://www.soundonsound.com/sound-advi ... r-keyboard

I'm undecided whether to even try and address the issue, or just implement a bunch of velocity curves with a "choose your fave" disclaimer. I have a sneaking concern that it would be better to address it at a lower level, but I lack the insight.

Hey! What's your favourite velocity curve?!

[RichardT]

For me, the best thing is a keyboard which is harder to press the harder it’s played, like a real piano. Even with weighted action electronic keyboards it’s easy to get rogue notes that are louder than they should be. Real pianos don’t seem to have this issue - things sound smoother.

So I think there are 3 kinds of velocity response

- how the physical resistance of a keyboard varies with pressure
- how midi note velocities are created by the keyboard
- how midi note velocities are mapped to sounds in instruments.

A lot of software instruments these days have their own velocity mappers, so I would be tempted just define one velocity map in the hardware to keep things simple.

I have to say that the only keyboard I’ve had that allowed the velocity response to be adjusted (by Novation) had the worst velocity response of anything I’ve owned. Perhaps by letting the user adjust it they felt they were off the hook for designing a sensible curve in the first place.

[adamburgess]

I'm trying to find a way to write this in words… Maybe it'll matter in your use case, probably not that much in the grand scheme of things.

Is the word I'm looking for 'Consistency'?

At least while testing, use the same finger, or use a mechanical device?? - so the playing field is at least a known quantity. How many variables are introduced on a 'graded' action keyboard with non-consistent finger strengths?

I do prefer a 'HARD' setting, as it's usually called. I REALLY want to hit it to get full velocity, but, that's cause I'm not particularly subtle.

As for commercially available stuff - I tried a billion curve settings over a good few months in an Arturia 88 keyboard - and sold it.

[BJG145]

For me, the best thing is a keyboard which is harder to press the harder it’s played, like a real piano. Even with weighted action electronic keyboards it’s easy to get rogue notes that are louder than they should be. Real pianos don’t seem to have this issue - things sound smoother.

Interesting comment - so in Martin's article, would that be the second convex curve...? ("Switching to the convex curve will give you greater control over louder notes.")

At least while testing, use the same finger, or use a mechanical device?

Yes, that would be the ideal. Not for the first time I think I need a robot arm.

[RichardT]

For me, the best thing is a keyboard which is harder to press the harder it’s played, like a real piano. Even with weighted action electronic keyboards it’s easy to get rogue notes that are louder than they should be. Real pianos don’t seem to have this issue - things sound smoother.

Interesting comment - so in Martin's article, would that be the second convex curve...? ("Switching to the convex curve will give you greater control over louder notes.")

At least while testing, use the same finger, or use a mechanical device?

Yes, that would be the ideal. Not for the first time I think I need a robot arm.

Yes, it could be.

[James Perrett]

At least while testing, use the same finger, or use a mechanical device?

Yes, that would be the ideal. Not for the first time I think I need a robot arm.

Or something like Knex, Lego Technic or a Thames and Kosmos set where you can make a device to prod the keys at different speeds by using different gearing.

[Wonks]

Several manuals I've seen where velocity curves are adjustable have the curves drawn. You could pick a keyboard, try mapping your sensor response curves to those output curves and see what you think.

[Wonks]

But you really need to look at the first part of the response curves. Overall they don't seem that different overall to me, and you don't want to add milliseconds of delay by waiting until the sensor is outputting its lowest value, otherwise you'll get the same key response time for a fast press as a very slow press.

With a ruler on the screen, the 'medium' press reaches the 150 line slightly quicker (~13) than the 'fast' press(~13.5), with the slow press having slightly more delay (~15).

No, they're not linear, but they don't need to be. For a basic keyboard you only need to pick one velocity value to chose to map to the selected velocity curve and produce an output. You're simply looking at the time taken for the key to move a certain distance to determine its velocity (though if you want to output more than one velocity per note as the key is pressed down you could still implement that. I believe the better electronic pianos utilise three sensors for velocity (two is standard) to better mimic a slow strike that speeds up or a fast initial strike that is held back at the end (I recently spent a couple of hours with a friend in an electronic piano showroom who was trying to make his mind up about which one to buy).

I'd be looking at trying to get better resolution from the sensor output, because at the moment, there's very little difference in the curves.

Have you tried a different orientation of the sensor?

[Wonks]

And of course the velocity value needs to be sent out as part of the ‘note on’ message, so you can’t hang around for 10-15 milliseconds determining the velocity or it will all sound rather laggy. (Maybe multiple velocity messages are best left to internal software instruments than MIDI driven ones).

[BJG145]

I'd be looking at trying to get better resolution from the sensor output, because at the moment, there's very little difference in the curves.

I missed off a crucial piece of information...the X axis.



This is the sensor data for three presses, captured by an Arduino loop as the key moved between two points; just after the start, and just before the end.

I'm calculating velocity by measuring the difference in time as the key passes between these points and there's a decent measurable difference in how long they take.

The graphs are very similar really, as you say, and they only have a slight curve. I think that means the velocity response is actually close to linear. But as has been said, I don't think I can test that with a mechancal prodder.

[Wonks]

Ah, yes, much clearer.

Yes, the curves should be very much the same shape as that is just proportional to the distance from the magnet to the sensor.

I don’t know what sort of timing intervals the samples are at, but obviously the less time you take to determine the velocity, the more responsive the keyboard will be.

Is it possible to rescale the sensor output so you are looking at a bigger Y-axis (presumably voltage) range over the first few samples?

[BJG145]

I don’t know what sort of timing intervals the samples are at

Thanks for the comments, it's helping me get my thoughts straight. I don't think there's enough info here to tell if velocity is linear or not. I'd need to set up a mechanical system and measure a load of velocity levels.

[Wonks]

The curve is basically the same shape for all curves, so you can assume that as a good approximation, the sensor output is directly proportional to distance between magnet and sensor, so if you measure distance travelled over a given time, then that will be directly proportional to the velocity.

But the greater the sensor resolution, the more accurately you can detect the velocity. Ideally you’d want a range of 128 (or greater) for the fastest velocity, so it’s easy to map to a 0-127 MIDI velocity value. But a range of 64 allows you to map in steps of 2, and 32 in steps of 4.

Most sampled instruments have maybe 3 or 4 velocity layers, so even a crude mapping wouldn’t show up much with those, though a modelled instrument should perform better with a greater range of velocity values.

So if the sensor is outputting a 0-1v signal, and the A/D is set up for a 0-5v signal, then boosting the sensor signal by 5x will increase your available resolution.

[Wonks]

Correction: The output isn’t directly proportional to distance (it’s a curve) but approximating to the square of the distance. As the magnet and sensor are close together and neither is a point, you’re getting a response that is somewhere between a squared and a linear response, but closer to a squared response.

So, if you want to calculate velocity over a fixed period of time, you really need to determine the curve formula, which Excel should do for you.

If you want to calculate velocity by the time it takes to travel a fixed distance, then you don’t need that, but 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.

[BJG145]

OK! Thanks for the science. This has been helpful.

[Wonks]

Does each sensor put out a slightly different output? There must be some manufacturing tolerances.

I was thinking that the rest position output of each key could be measured and stored as a reference point during a self-calibration routine on power up or as part of a selectable calibration process. If one sensor had an ‘at rest’ output of 215 and another of 230 and another of 199, then a fixed general ‘start’ value for velocity for all keys wouldn’t work well, so each key really needs its own value.

I’d also check if the value changes with horizontal and vertical orientations, and if it changes significantly with respect to its orientation with the Earth’s magnetic field. And whether the nearness of an iron or steel object has any significant influence. It’s vaguely possible a chunky metal watch could affect the output, but I have no idea if it would be meaningful or not.

I really don’t think you need a solenoid. It’s just an on/off action and if positioned too near, its strong magnetic field will affect the sensor. You already have most of the information you need. You aren’t making samples that need repeated velocity hits. You only really need to determine output curves at minimum and maximum velocities, which you can do with your finger.

Minimum velocity is probably the hardest limit to set, so you need to think about how slowly you’d really hit the key in a musical application. E.g. would you ever take two seconds to fully depress a key?

[Folderol]

I think Wonks has covered almost my exact thoughts. Also are these devices responding to just the distance moved or distance + velocity. I've not done any work with hall effect devices, but conventional magnetic very much respond to both! The differences you were finding suggests it might be similar. In any case you would want both the start and end values of each individual device stored.

[Wonks]

I can’t see the need to store an end value myself, as provided you can get good enough position resolution, I wouldn’t work on the full switch travel range, simply in order to speed up note sending for slow velocities.

[Folderol]

I can’t see the need to store an end value myself, as provided you can get good enough position resolution, I wouldn’t work on the full switch travel range, simply in order to speed up note sending for slow velocities.

You need this to get reasonably consistent normalised curves. Quite tiny lateral position differences will have more effect, the closer the armature is to the sensor.

[Wonks]

I’m still not getting why you currently need to save the end values in the device. You’re calculating standard curves which you then use to create a lookup table for each velocity curve you want, and that’s what goes in the unit.

You should know from the test data whether the curves have similar output ranges e.g. 215 to 105, 210 to 101, 207 to 99. If so, you only need to know the starting value and look for either the time for a fixed differential value reduction or else the amount of reduction in a fixed time.

So before getting too complicated, I’d first establish output variations from different sensors and whether the curves followed different shapes for each sensor. This is where a controlled pressing device would be handy so you could get repeatable results for each key.

I was wondering whether different value weights dropped on the key down a tube might do it? Or maybe a pivoted wooden ‘finger’ with different weights on the end?

At the moment, if Ben’s fast/med/slow output plots looked very different to each other, then you’d probably need more complicated maths, or a different velocity method; but for the one sensor the curves all look the same, just stretched out over time. Certainly enough for a close approximation to what’s actually happening.

So we really need more data on how well the curves and outputs from different sensors match.

There’s also a limit to how much precision you can apply to pressing a keyboard-style key with maybe 2-3mm of travel, along with the exact way its pressed e.g. constant velocity until the key stops, fast then easing, or slower then fast. You don’t want to go too OTT with the small details.

[BJG145]

There’s also a limit to how much precision you can apply to pressing a keyboard-style key with maybe 2-3mm of travel

For info, I'm using Lekker L60s. I like these. (4mm.) I've just ordered a batch of the lighter L45s. They're normally used in analogue gaming keyboards like the Wooting Two.

[James Perrett]

I mentioned this thread to my lad and, using parts from his Thames and Kosmos Remote Controlled Machines set,



he built a motorised key player. You can see a video of it in action at

https://photos.app.goo.gl/rRazjhq64mGpS2X39

There's only one speed at the moment but by changing the geometry of the lever you should be able to vary the note velocity.

[BJG145]

Here's a question for you then.

1) Martin describes these velocity curves as linear, convex, saturated, and concave. (X-axis is key speed and Y-axis is MIDI note velocity.)



2) This curve shows sensor output levels as the key is pressed. (X-axis is time, Y-axis is sensor output.)



3) Velocity is calculated from the time it takes for the sensor level to fall between these two points as the key is pressed. (As the speed increases, this falling time difference is remapped onto the MIDI range 0-127.)

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

[BJG145]

I mentioned this thread to my lad and, using parts from his Thames and Kosmos Remote Controlled Machines set, he built a motorised key player.

[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.