[sdiy] MIDI volume to volts formula

[rsdio at audiobanshee.com]

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
>