[sdiy] MIDI volume to volts formula
Mikko Helin
maohelin at gmail.com
Wed Jul 11 13:19:23 CEST 2018
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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://synth-diy.org/pipermail/synth-diy/attachments/20180711/01a5260d/attachment.htm>
More information about the Synth-diy
mailing list