Who defines the preset sound at MIDI velocity 64? ...

Velocity is guided by mechanics rather than tone. In Pianoteq, this would be the momentum with which the hammer hits the simulated strings. In sampled VIs, this would be the strength with which a key is hit (VSL use a "robot finger" to make it repeatable).

So, if different instruments sound different at the same velocity, that would be a fair reflection of the playing experience on different instruments: variable outcomes for the same input.

The editorial choice that a human would make would be to define the maximum force for vel=127 (as well as the minimal for vel=0, as I imagine we wouldn't start from nothing). I would speculate in pianoteq this choice is consistent within instrument groups (ie. obviously a different choice between the steinway and a steel drum).

So vel=64 falls out of the wash.

Is Pianoteq using a "robot finger" too since day one?
With 127 fixed mechanical velocities to sample the original pianos and then design a physical model of the same loudness and sound dynamics?

If so, the mechanical velocity 64 is fixed since the beginning and the physical model would not make a difference if two original pianos have a different dynamic response.

I know that Pianoteq is not a sampler. But don't they use samples for orientation that the physical model is similar to the original piano?

Not important for this thread, but my opinion is, that 127 levels are good-enough, yes, ... but only if the distribution/mapping to mechanical levels is well done. Where many controllers fail. Who or what determines, how a pianoteq piano preset should sound at vel 64, if not a (algorithmic) "robot finger"?

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))

An iterative process is possible, which means there is a human factor /arbitrariness  in the velocity response of each instrument preset. Then it is unlikely, that a one-fits-all, global velocity curve for an individual midi controller exists.

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 ...

... 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.

Of course the player himself is free to choose 127 value pairs in the map, no question. A good thing. But this freedom already has some limits, because not all combinations sound like a real piano and planless iteration can be too time consuming (and  even fruitless). Not everyone's cup of tea.

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).

I thought, I have written all I had to say . Anyway.

... 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.

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)

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??

Okay, after reading this thread more thoroughly, I am thinking maybe an analogy to color management in professional photo editing would help (for those who may understand).  It's similar to the two separate problems daniel_r238 referred to.

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.