[sdiy] MIDI velocity

[rsdio at audiobanshee.com]

On Apr 6, 2016, at 4:01 PM, Richie Burnett <rburnett at richieburnett.co.uk> wrote:
> Some actual transit times measured from my Fatar velocity keybed:
> 
> Hard hits average around 1.5ms to 2ms,
> Medium hits average 15ms to 20ms,
> Soft hits anywhere from around 150ms to 250ms,
> 
> These are the times between the first closure of the "early" set of contacts at the top of the key's travel (Fatar calls them "break" even though they are actually normally open contacts,) and the first closure of the "late" set of contacts at the bottom of the key's travel (Fatar calls them "make".) I found it impossible to get transit times below 1.5ms without hitting the keys much harder than I would feel comfortable doing.
> 
> Looking at those figures it does seem that a logarithmic relationship is a good fit, as the time goes up by roughly one decade from "hard" to "medium", and up another decade from "medium" to "soft".
> 
> Polling the complete keybed every 1ms is fast enough to capture even the hardest hits, but it doesn't look like it gives much timing resolution at the top end of the velocity range.  I wouldn't be surprised if some velocity sensitive MIDI keyboards don't output all of the 127 possible velocity values if their timing resolution is quite coarse at the high-velocity end of the scale.

If these timing measurements are converted to velocity with a strict "1. / time" formula, then 1 ms resolution results in only about 21 unique 7-bit velocity values. I did some calculations with successively smaller timing resolutions, which I'll list here (number of values first, then number of microseconds between measurements):

#, microseconds
11, 4000
13, 3000
16, 2000
22, 1000
30, 500
41, 250
56, 125
75, 62.5
96, 31.25
117, 15.625

I calculated the above by converting "1. / time" to a 7-bit value and keeping a histogram. Then the histogram was used to count unique values. Basically, even a large table would have the same value repeated many times in sequential indices. There is some saving possible here, though, because once the table reaches the minimum velocity of "1" your table can end; any timing count larger than the maximum table index just gets converted programmatically to a "1" for velocity.

It's not really feasible to have an interrupt rate of 15.625 microseconds. That would be 64 kHz! I'm not even sure that we need as many as 117 unique velocity values, just because there are 127 possible in MIDI. Besides, finer timing resolution means that you need a longer lookup table.

Other curves besides a strict "1. / time" would make it easier to generate more unique velocity values, although any practical curve would have some repeated values.

Brian Willoughby
Sound Consulting