[sdiy] MIDI volume to volts formula

[Tom Wiltshire]

That thread starts off very badly, with someone claiming that pianos “respond to force not velocity”. That this is not true can easily be demonstrated by pressing a piano key down very hard but very slowly. Nothing happens.

The piano key is a lever which sets the hammer in motion. Once the hammer leaves the key mechanism, no amount of hand-waving, pressing, or wiggling makes any difference. The only thing which changes is the speed with which the hammer hits the strings.

The relevant bit of physics is therefore the equation for momentum, Momentum = mass x velocity, since it is the momentum of the hammer which determines the volume of the strike. That momentum is directly proportional to the velocity of the hammer.
Whether hammer velocity is directly proportional to key velocity is a different question, and whether key velocity is the best way to measure hammer momentum is also open to question.

==================
       Electric Druid
Synth & Stompbox DIY
==================

> On 11 Jul 2018, at 12:19, Mikko Helin <maohelin at gmail.com> wrote:
> 
> Typical MIDI keyboard with switches and timer counters lacks when trying to simulate acoustic piano on which the dynamics depends on acceleration and mass of the hammer (mass * acc = force). There's some discussion on it on NI forum:
> https://www.native-instruments.com/forum/threads/velocity-issue.62444/
> Some modern digital pianos have therefore switched to multiple velocity measurements (like triple sensor keys on Kawai's RM 3 Grand II action) or optical scanning.
> 
> On Wed, Jul 11, 2018 at 9:59 AM <rsdio at audiobanshee.com> wrote:
> Sure.
> 
> http://audiobanshee.com/software/Velocity.dmg
> 
> The application only opens the first MIDI port that it finds, so if you have more than one MIDI port then you have no control over which one gets opened. The histogram updates as MIDI Notes come in. In addition, an estimated curve is drawn in red as the new values come in, but it’s not a terribly accurate curve since there’s no way to determine the input data that the synth is working with. For my VFX, the fact that the top five velocity values are all available, but there are gaps everywhere else, shows up as a curve with a slope that tapers off at the top (like a bit of soft saturation, if you will). I may try to find a way to better estimate what the transfer function might look like.
> 
> I added Save and Open menu items.
> 
> The file format is the text, “MIDIVelo” (without the Standard C zero terminator), followed by 16 bytes, for a total of 24 bytes. Each byte represents eight velocity levels, starting with the least significant bit, from velocity zero (which will always be missing since it’s a Note Off) to velocity 127. The extension is .Velo - I decided not to bother saving the actual histogram counts, even though they’re graphed in the application, because the count is irrelevant. What really matters is whether the velocity has ever appeared, or not. Thus, a 128-bit map in 16 bytes is sufficient.
> 
> If someone wants to automate a process to upload such files to a Google spreadsheet, then the above description should be enough to get you going. I don’t think they’ll be much use, and you’ll probably need a better way to visualize the data anyway - at least something better than a spreadsheet.
> 
> Brian
> 
> p.s. I’m assuming that most keyboards have a time reference in the form of a counter. Thus, “velocity” measurements are actually timer counter values. The fastest velocities should be coarse, but if they’re mapped well then the coarseness won’t be apparent in the histogram. The slowest velocities could be rather large counts, with plenty of fine resolution, but some will be clipped to the lowest velocity having a value of 1. The fact that slower velocities might be further apart may also not be apparent if the velocity mapping discards the excess resolution. If anyone has ideas for alternate graphing calculations, just let me know.
> 
> 
> On Jul 10, 2018, at 2:35 AM, Hugh Blemings <hugh at blemings.org> wrote:
> > Hi Brian, All,
> > 
> > On 10/7/18 16:34, rsdio at audiobanshee.com wrote:
> >> It took a month before I got started on a MIDI Velocity histogram app, but only a couple of hours to actually write it (thanks to CoreMIDI, etc).
> >> 
> >> I’ve only done a quick test with an Ensoniq VFX set to the defaults, so I’ll need to spend more time with other keyboards as well as looking into the velocity curve settings options.
> >> 
> >> With the VFX, I’m only seeing 45 unique velocity levels (not counting 0, of course). The VFX reaches up to velocity 127, as well as 126, 125, 124, and 123, but then there are gaps between the remaining velocity values at 120 and below.
> >> 
> >> Based on your description, the DX7 only implemented 5-bit velocity instead of the full 7 bits.
> > Two questions come to mind on this;
> > 
> > Would you be happy to share the app ?
> > 
> > If so, does it make sense to build an export function and then dump the resultant data into (say) a Google Spreadsheet so that we can build up an archive of the histograms ?
> > 
> > I realise that without actual velocity measurements from the keyboard itself or timings from the contact closures the data only really gives general resolution/bit depth info, but might be interesting anyways ?
> > 
> > Just a thought :)
> > 
> > Cheers,
> > Hugh
> > 
> 
> 
> _______________________________________________
> Synth-diy mailing list
> Synth-diy at synth-diy.org
> http://synth-diy.org/mailman/listinfo/synth-diy
> _______________________________________________
> Synth-diy mailing list
> Synth-diy at synth-diy.org
> http://synth-diy.org/mailman/listinfo/synth-diy