[sdiy] MIDI volume to volts formula

[rsdio at audiobanshee.com]

Well, it’s not literally “TIME” but something like “1 - t” or, more accurately, “c - t” where c is a constant like 127. “t” is time in both functions. Rather than reciprocal time, it’s negative time (because of the counter decrementing).

As I mentioned earlier, Velocity is distance over time, or “d / t” but distance is fixed for a piano action so that becomes “1 / t” effectively. For minimal processing, MIDI keyboards transmit “c - t” instead of “1 / t"


On a related note, when mapping an input range of 128 values to an output range of 128 values, the only function that actually produces 128 unique values is the linear 1:1 mapping. This assumes we’re not using real, floating point numbers because MIDI is discrete integer values. Every other map or curve will not actually produce 127 different velocity values on output.

Perhaps Yamaha decided to use a curve that would have only produced 100 distinct outputs anyway.

Another consideration is that if a counter is running fast enough to detect small differences for fast velocities, then the count might actually have to start with a much larger value than 127. They might even start with 1023 and count down, but mapping 0 to 127 and 1023 to 1 (in other words, compressing the 1024 range to a smaller 128 range). I haven’t looked at the actual keyboard scanning rates or velocity histograms to see what the numbers show.

You guys now have me interested in collecting histograms of the MIDI velocity values for my various synths. Of course, I’ll have to measure each velocity curve separately if the keyboard offers user-selectable curves.

Brian


On Jun 7, 2018, at 2:29 AM, rburnett at richieburnett.co.uk wrote:
> This same discussion came up a few years ago.  One of the things that seemed apparent to me is that (for some keyboards at least) the MIDI "velocity" byte that is transmitted is not a *velocity* measurement at all.  It is actually the result of a digital counter counting backwards from 127 towards zero, measuring the *TIME* taken for the key to move from the top set of switch contacts to the bottom set of switch contacts.  So there is clearly a reciprocal relationship between velocity and time at work at the keyboard end that generates the MIDI messages.  And then there is also a log weighted perception of volume for audio signals of different amplitude (as well as Fletcher Munson, A-weighting, etc.) going on at the synthesis end too.  So it doesn't surprise me at all that there are some pretty funky curves required to map the real parameter of "transit time" to "signal amplitude", in a way that perceptually feels like the correct mapping of "velocity" to "volume".
> 
> -Richie,
> 
> On 2018-06-07 09:39, chris wrote:
>> I don't even think the actual transfer function is really important.
>> So you could use exp, inverted log, square (normalized to 0..1), gamma
>> (as in graphics), or even a quarter circle (ok, may degenerate due to
>> infinite derivative) - as long as 0 maps to 0 and 127 maps to 127
>> (wouldn't be necessary, but seems to be common).
>> Add some spicy coefficients or combinations of the above to create a
>> couple of variations, so the user can select from a handful of options.
>> I think it's just about somehow bending the linear transfer
>> funnction towards harder or softer without introducing any steps.
>> Maybe even the big companies don't put much emphasis on this, I remember
>> the DX7 keyboard only generating velocity values up to 100. DX patches
>> really come to life when played from a piano action master keyboard...
>> Chris