I mean to say that on an acoustic piano a freefall acceleration produces a forte. Nb my arm weighs more than 500g

Okay, you talked about an acoustic piano and not a MIDI controller. Two notes:
- Your arm is not free falling (I hope so ;-).
- If a weight of 500 g placed on a middle white key of your acoustic piano produces "forte", a common hammerweighted MIDI controller should output vel=96 according to Pianoteq's default MIDI mapping. Which hammerweighted MIDI controller outputs vel=96 with 500 g at normal touch settings?
For better understanding see my visualisation of PTQ's calibration assistant in the old thread
"Analog" MIDI Keyboard Calibration Assistance?

By the way, it's funny (or a bit frightening?), how fast AI absorbs a loose hypothesis on the internet. I have used the legacy google search because I wanted to know, if eventually someone else had played around with 500 g before ...

Question to google: MIDI velocity with a weight of 500 g?
========================================================================================
Overview with AI

Using a 500g weight to test MIDI velocity is a recognized, simple method to evaluate a keyboard’s "fingerprint" or velocity response at a, constant downward force, often used for calibrating controllers in software like Pianoteq.

    Test Method: A ~500g weight is placed on a middle white key (e.g., C4) to measure the resulting MIDI velocity value, which typically tests the sensor's response to a consistent force rather than a dynamic one.
    Results: Placing a 500g weight on a key can generate a specific, repeatable MIDI velocity value to help standardize key responses at the factory default curve (e.g., "Normal" or "Linear").
    Context: This test is specifically mentioned in the Pianoteq forum when analyzing the velocity response of the Vidal MIDI piano controller.
    Calibration Note: If you do not have a calibration weight, an equivalent is 100 US nickels or 500mL of water.

Note: The exact MIDI velocity value produced by 500g will vary depending on the keyboard's internal mechanism and velocity curve settings.
=========================================================================================

1) What Red, Green, Blue (RGB) value combination represents what color?
2) How to ensure people editing on their own monitor produce a color photo that looks as they desired on a reference monitor (and on other people's monitor, and on print).

#1 is an engineering problem, that can be precisely measured and defined.  RGB value mapping to color is a fixed standard for a color space.

#2 is a device calibration problem.  It is resolved by introducing a "color profile" for each brand/model (or even individual) monitor.  The color profile accounts for the difference in capability and accuracy of the monitor's color producing mechanism (tube vs LCD [TN vs VA vs IPS] vs OLED).  To create the color profile, a calibration device (kinda like an accurate camera) is used to capture the reproduced colors (RGB values) from known input signals (RGB values) and generate a mapping so that the output is the same as the input.  On all monitors that their respective color profile has been applied, the same RGB input will display exactly the same to the person viewing it.  In other words, this allow one person to edit a color photo on one monitor, then go to another monitor to see the same result and continue the editing, and the final result is guaranteed to look exactly as this person desired when viewed by other people on their monitors, or viewed on print (which required the printer to have it's own proper color profile, too).

The analogy to piano sound libraries would be #1 is the MIDI to tone mapping, and #2 is the velocity curve that should be generated and applied to each brand/model/individual digital keyboard.  Ideally, when both are done correctly, for a particular digital piano sound library, one can play on any keyboard, using the same gesture (force and style of movement), and produce the same performance in both tonal color and dynamics.

Of course, MIDI to tone mapping should be different for each modeled or sampled acoustic piano.  That is the equivalent of color space in the above analogy, such as sRGB, Adobe RGB, etc.  Also, there is nothing in this mapping that says it should be linear (or logrithmic, or even conform to any formula) to loudness or dynamics.  It's a one-to-one mapping per MIDI velocity, matched by tone or color.

Another thing that I omitted is loudness or volume.  This is where the analogy falls apart a little.  RGB value does include brightness in itself, and when one calibrates a monitor, the target brightness is precisely set as well.  Each individual acoustic piano cannot independently vary tone and volume.  However, there is the brightness knob on the monitor.  And digital piano sound library can indeed set the playback volume without changing the tone color.  In practice, a photo editor is not supposed to change brightness of an already calibrated monitor.  Similarly, if the gain staging is carefully calibrated for the room on the audio interface and studio monitors, then the pianist probably shouldn't mess with the volume knob either.

If I do a true free-fall (starting from the top key contact point) to the keybed, I get a strong forte approaching a fortissimo.

Really? Your midi controller (at normal/factory touch setting) generates even more than vel=70 like my example Korg B2 with a 500 g weight??

groovy wrote:

The other half (and the main hypothesis) is its relationship to human perception (I called it "muscle memory" above). I postulate that our hand/forearm is sensitive if it is free falling (=1G), accelerating with >1G or decelerating with <1G.

Ah ok I think I get you now, thanks for clarifying. I had trouble following because I'm not convinced by the postulate (1G = medium effort/max sensitivity). If I do a true free-fall (starting from the top key contact point) to the keybed, I get a strong forte approaching a fortissimo.

However, you are right that pianists use gravity as a fixpoint to adjust their playing, but the "armweight" is mediated by elasticity in the fingers, which act as a buffer. When you approach an unfamiliar instrument you will calibrate yourself towards it, changing the coupling of armweight to keys by changing your finger elasticity. The 1G hypothesis would be at the extreme end of that range, where your wrists and fingers are perfectly stiff - and obviously you couldn't play anything like that.

So I believe that the acceleration that should produce an mf is pretty subjective, and usually informed by your experience with the key action of a specific acoustic instrument you want to replicate. And it's that acceleration that should be velocity-mapped to the VI's mf layer (which may or may not, but probably will, be around vel=64)

I agree with you Daniel . Gravity  plays for sure a pivotal role in piano playing and piano mechanic action , the ideal velocity curve for a given person , and specific keyboard and the response of the virtual library to midi input  ( in this case pianoteq) For those interested with the later , the best academic document I found is the famous article from
Dannenberg :
https://www.cs.cmu.edu/~rbd/papers/velo...mc2006.pdf

Imho , Modartt has the right approach with their velocity curve assistant relying on human ear for specific points in the ppp to fff range but has some limitations .
First of all the number one issue with a lot of DP’s today is the discrepancies of midi values velocity  for the same force from one key to the next . This problem needs to be solved first . Static weights is useful for low velocities where static down weight is predominant but doesn’t work very well with higher velocities where inertia plays a much bigger role . The best is probably to play scales at slow speed with various intensities multiple times and correct outlaws with piano internal firmware such as the one that exists in some controllers or use midi transform scripts in a DAW like Logic Pro , reaper or VST hosts such as gig performer to adjust midi . Once done , I think  manual adjustment for specific points in the curve 5 or 6 points suggested by groovy make sense  and are best done by the user himself , after adjusting the peak volume in SPL levels corresponding to the instrument being modelled .  Italian notation is based on simple human ear perceived volume . Mp being normal voice speaking , Mf slightly higher , f loud voice speaking , fff corresponds to the maximum output in dB you can get , p is lower than normal voice speaking  etc… I think it is very important to rely on the real player auditive adjustment , specifically for playing with Digital pianos that don’t send a lot of haptic feedback . The most important cue you get is what you hear and your playing adapts subconsciously to the perceived loudness to generate a given dynamic , that’s why automating velocity curves without human intervention is unsatisfactory.

The other half (and the main hypothesis) is its relationship to human perception (I called it "muscle memory" above). I postulate that our hand/forearm is sensitive if it is free falling (=1G), accelerating with >1G or decelerating with <1G.

Ah ok I think I get you now, thanks for clarifying. I had trouble following because I'm not convinced by the postulate (1G = medium effort/max sensitivity). If I do a true free-fall (starting from the top key contact point) to the keybed, I get a strong forte approaching a fortissimo.

However, you are right that pianists use gravity as a fixpoint to adjust their playing, but the "armweight" is mediated by elasticity in the fingers, which act as a buffer. When you approach an unfamiliar instrument you will calibrate yourself towards it, changing the coupling of armweight to keys by changing your finger elasticity. The 1G hypothesis would be at the extreme end of that range, where your wrists and fingers are perfectly stiff - and obviously you couldn't play anything like that.

So I believe that the acceleration that should produce an mf is pretty subjective, and usually informed by your experience with the key action of a specific acoustic instrument you want to replicate. And it's that acceleration that should be velocity-mapped to the VI's mf layer (which may or may not, but probably will, be around vel=64)

So we can just try to adapt our individual controller that we have - as you wrote - "enough sensor resolution in both the softer and louder direction". Then chances are good, that the VI gets what it wants and the player gets what he wants haptically.

Were you just describing the Velocity Curve feature in Pianoteq (and many other sampled VSTi players)?

... that 1G is replicable is just the half of the story. The other half (and the main hypothesis) is its relationship to human perception (I called it "muscle memory" above). I postulate that our hand/forearm is sensitive if it is free falling (=1G), accelerating with >1G or decelerating with <1G. If so, why not map:

>1G -> f - fff
=1G -> mf/mp
<1G -> p - ppp

Thats basically what I did. And it works suprisingly good with my individual midi controller. If it works with other midi controllers, it eventually is the "missing link" between the mechanical and the MIDI domain.

I tried to find 5 defined mappings, because that is what Ptq's own calibration assistant does with a very similar algorithm. Theoretical maximum are 127 mappings, minimum two mappings [0,127; 0,127]. Five mappings are reasonable, as they cover ppp, p, mp/mf, f, fff and their interpolations.

... no, I don't know the real model keyboard (Steinway, Petrof, Bösendorfer etc). The only interface we have to Pianoteq is, that it wants the following midi output from an individual controller ...

0 for ppp
32 for p
64 for mp/mf
96 for f
127 for fff

So we can just try to adapt our individual controller that we have - as you wrote - "enough sensor resolution in both the softer and louder direction". Then chances are good, that the VI gets what it wants and the player gets what he wants haptically.

... but we don't play the real piano, we just have the midi API ppp - fff.

... thats why I had to map the output of my individual controller from 70 to 64 at 1G.

... of course not. As I already wrote my controller is limited to ~105. That is fixpoint Nr. 5 of five in my "method", analog to Ptq's calibration assistant.

Are we trying to calibrate the velocity layers so that the playing experience on our controller keyboard exactly matches the model keyboard? If so, consider (a) all model instruments produce a different dynamic at 1G acceleration, and (b) all controller keyboards produce a different MIDI velocity at 1G.

Or is the idea to replace the velocity curve with one calibration number (aka "at 1G my controller produces vel=70, so construct a velocity map where 70 -> 64")? If so consider that not all controllers use the full velocity range (e.g. mine can only produce velocities up to ca. vel=110, even if I hit a key with a sledge hammer). So you don't get an optimal velocity curve by calculating the curvature from the mid point relationship.

Or are we trying to do something else?

Back to my (hypothetical) more deterministic approach: 4 of 5 calibration points in the velocity mapper I described already. For the fifth point (forte f) I had no idea so far. For a good guess it seems to be sufficient to connect the found points at mf and fff with a straight line and place point f on it (in other words linear interpolation). That's the same as just using the 4 known points and connecting them.

With a few weights, especially the ~500 g besides 250 g and 125 g, the result is now a mapping of the 5 main calibration points, which is working astonishing fine with my midi controller. For finetuning and personal preferences it seems to be enough to move those points not more than 1 or max. 2 levels to the left or right (similar to PTQ's calibration assistant).

So you vote for algorithm? ->
Quietest note of the original piano is defined as velocity 2 and loudest as velocity 127. The other volumes are generated by a term similar to D  x ([log (velocity) / log(127))

No I don't vote for an algorithm . I am just stating that velocity values influences both timbre and volume and that for a given Dynamic range perceived volume is logarithmic rather than linear. The above logarithmic perception of volume is one thing, but the variation of timbre is a different beast and influences  the choice of  a velocity curve shape which will best  determined  by the player himself based given his personal preferences for a bright sound or a warmer sound depending on the type of music he plays and depending on the keyboard he uses.

Of course it makes sense to set up your VI so that vel=64 is "something in the middle" so that you have enough sensor resolution in both the softer and louder direction, [...]

... this is where the dependency chain starts, at the designer/creator of the VI preset (not influenced by the user). Then comes a velocity mapper (user domain), then the midi controller hardware (user domain). If there is more or less arbitrariness in the start definition of "something in the middle", it has impact on the rest of the chain. Therefore my initial question, who or what defines that initial "in the middle" and whether it is done systematically inside PTQ.   

Yes, all that we know is, that the designer "wants" a velocity mapper output of 64 as input for his center response . How it translates to the rest of the chain, is free ... but maybe not as free as we think. If the (earth) acceleration of 1G of a hammer action is the mechanical analogon to a heard "something in the middle", it makes calibration easier. With ~500 g we get a good approximation of 1G. Together with the circumstance, that all digital hammer actions have more in common than what divides them, the chain can be linked via the velocity mapper. In my example a keyboard note outputs vel 70 at 1G and is velocity-mapped to 64 which is what Pianoteq "wants" for a  normal touch, neither light nor strong.

BTW, wonder if this concept works on the moon ;-). Let's call the lower acceleration on the moon 1M instead of 1G. I suppose, the midi output of a drop weight, that accelerates the key with 1M on the moon, should be mapped to the "something in the middle" response (64) in Pianoteq.

Of course individual finetuning of this medium response +/-2 levels remains a good idea and it has to be counterchecked on other midi controllers than just mine.

1. How does one calibrate a piano action for an optimal, expressive range of dynamics?, and
2. How does the MIDI velocity parameter get mapped to audio samples* to establish a realistic playing response?

One observation I'd like to offer is that these are two separate issues: Problem (1) is a hardware configuration issue independent of MIDI (acoustic instruments have to solve this as well), and for problem (2) the creators of the VI do not know which hardware they will be played on and how it is configured, so they can't make predictions like "aha, a 1G acceleration will produce vel=64 on every keyboard".

In other words there is no fixed relationship between what is done to a keyboard key vs the resulting hammer/sensor action (which informs the MIDI velocity) vs the "correct" sound to produce in this moment. (On a pedantic note, I might remark that there isn't a fixed relationship between the dynamic, which is a subject of musical interpretation, and strength of attack, either: an mf over here is different to an mf over there. But that's beside the point.)

Hence why velocity mapping is so essential.

Of course it makes sense to set up your VI so that vel=64 is "something in the middle" so that you have enough sensor resolution in both the softer and louder direction, but that doesn't suggest there's a (need or possibility for) vel=64 being calibrated to a particular attack strength, or dynamic.

*in a sampled VI

Isn't it human to assume that the middle velocity level is associated with the medium / standard / basic response of a virtual instrument? It wouldn't be rationale to think, that the medium response per design is chosen at low vel 32 or  high vel 96 for example. But if humans are iterating it can happen, that one designer balances the medium response of a preset at 61 and the other at 66. Change your preferred velocity curve at mezzo-forte in this magnitude and a preset feels and sounds significantly different.

I have a steep hypothesis at the moment, that a physical background determines the mezzo-forte range of a midi controller:

It is at the point, where the key accelerates with 1G (= 9.81 m/s²)

Why? Based on the graph that has been mentioned in a parallel thread recently:

It seems that the muscle memory "feels" when the hand is accelerated with more than 1G (mf to fff) and slowed down with less than 1G (mp to ppp). From the graph I learned, that with a weight of >=500 g a key acceleration of 1G is reached with a common action. It might be more than a coincidence, that I had calibrated my velocity map just by ear and trial & error to vel 72 at mezzoforte (64) long before. Practically the same velocity ~70 that my midi controller outputs at 1G under factory-defaults.

With this hypothesis the mezzoforte point (64) in the velocity curve can be mapped to the midi velocity at 1G (in this example 70 -> 64). The pianoteq calibration assistant calls this center point "normal touch, neither light nor strong" / "intermediate velocity".

But this is just one fixpoint of five used by the calibration assistant. Would be nice to deduce the other four points of the curve similarly, they seem to be less determined. For the lowest (controllable) velocity, I have chosen the point, where the rubberdome contact collapses under a static weight (can be felt with the fingertip, a bit like fake-let-off). With 100 g the rubber dome holds the weight, with 125 g it collapses (I don't take smaller intervals than 25 g for efficiency).
So I define that calibration point with 125 g.

A higher grade of arbitrariness has the calibration point "low velocity" "light, piano, touch". Between 125 g and 500 g I have chosen 250 g for this calibration point. It is in between the former values (of course) and the half of 500 g. And 125 g is the half of 250 g. I hope for some hidden math, that it makes some sense ;-), at least it provides a very similar value like my old trial & error curve.

The fff mapping is relatively uncomplicated, because my controller seems to be limited somewhere at 105.

You may ask at this point, where is calibration point 4, the forte f mapping? I have no idea at the moment, how to map this point other than trial & error ...