Okay, so I did another back-of-the-envelope estimation of this issue, this time reversing the role of time and space, and the result is not so bad. @JayKominek you are probably interested in this (if you haven't already done it on your own).
For this discussion I continue to make the assumption of the hammers reaching 7 m/s velocities during fortissimos, and of a worst case (in terms of time/distance travelled) escapement settings at 1mm (typically it should be regulated at 1.5-2mm).
The velocity of 7 m/s is equivalent to a more conveniently thought of 7 mm/ms, which means that the hammer travels the escapement in 1/7 of ms, i.e. 0.14ms
If we are sampling each channel at 8kS/s that means that there is one sample every 0.12ms, so it's possible to have at most 2 samples during escapement travel, but most likely there will be only one. But let me assume we can always get two samples (if we don't we can increase the letoff or increase the sampling frequency modestly, so let's keep that assumption for now and I'll get back to this at the end of this post).
Assuming there are exactly 16 bits of ENOB data and about 40mm of total hammer travel, and assuming the sensors are linear enough and well biased, let me make the back of the envelope estimation of having 65,536 levels in those 40mm ~ 65mm or about 1,000 levels per mm. Some of these assumptions (linearity for sure) are most likely not valid, but I think that 1,000 levels on the last mm can be achieved with some care into powering the LEDs appropriately and biasing the phototransistor for the purpose.
So let me repeat the previous assumptions:
- we can measure two data points during hammer travel during letoff
- the distance between these two data points is about 1/7 mm or 0.14 mm
- each of these two data points is measured with a resolution of about 1/1000 of a mm
Now, if we further assume that resolution is close enough to the accuracy, we can conclude that we can measure this distance with about 1% accuracy.
Finally, I'm sure that the time accuracy between the samples have negligible inaccuracies, so we can conclude that our v=s/t will have a 1% accuracy too. From previous conversations (based on the same PDF linked above), we know that the actual MIDI velocities must be logarithmic in the raw physical velocities. That translates in 2% raw accuracy at high velocities being enough to get 1% accuracy in MIDI. Of course in all this I am neglecting the Savitzky–Golay filtering (or other sophisticated way of computing raw velocity) but I'm pretty sure those will not change these outcome substantially (especially since I'm doing back-of-the-envelope estimate and not full analysis).
So in conclusion, 8kS/s (or marginally higher) can be adequate, provided that the letoff is regulated in such a way to get two "free flight" samples (or equivalently that the pianist does not have a playing style in which he/she changes the speed at the very end of the keypress) -- and provided that all the other assumptions described above are met. So one does not need super-high sampling rates if one has fast enough, and if one has high-resolution enough, sort of what is hinted at https://github.com/jkominek/piano-conversion/discussions/31
Now (and this brings us back to the one vs two samples taken during let off), this require the software to be written by keeping this fact in mind, otherwise there could be missing notes. @gzpiano this might be the problem you are experiencing which is what triggered this thread? This can happen if the software triggers MIDI note-on only when the hammer is detected "close enough" to the sensor, and computes the velocity only in that circumstance (at least that's how I wrote my first version of my software in an effort to keep compute resources low). It is possible that the hammer is never detected that "close enough" because it travels too fast for the given sampling frequency. However, the software can easily consider the velocity too and estimates the next expected position, and realize that it would never see the hammer closer to the sensor because it would bounce before the next sample is detected. Then it can trigger the MIDI note-on with the best estimate of velocity it has, "regardless" of the position of the hammer (well, not completely "regardless", but with a much larger "close enough" and I'm talking sub-ms time here, so it won't be at the wrong time). This is easily distinguished from a apparently similar case in which the hammer is travelling so slow that it never reaches the sensor, but only if velocity is taken into account to decide whether or not triggering a note-on!
