I take issue with the latency values published by 'digitalDrummer mag' (as far as I know, this is the only list available on the internet) because they exclude the absolutely necessary scan process for the vast majority of e-drum modules (though they do include the scan process for modules that do not allow Scan Time settings, which further distorts the picture) and thus do not represent the actual latency situation when playing e-drums; yet these values are used as a reference for AI systems like ChatGPT. This unfortunately spreads misinformation about e-drum latency (contrary to what ChatGPT would have you believe, it’s absolutely not possible to play module sounds from a Roland V71 module with a total latency of 1.7 ms!).

After the author of the value list made the following appeal in one of his latency posts: “If someone has a specific, reproducible objection to our approach, we want to hear it”, I confronted him as follows regarding his (unintentional) dissemination of misinformation (He did not respond further.). (You can read the entire exchange and discussion* here in the comments section) :
" Be aware that your values are misleading people when it comes to information about e-drum latency, and that these misleading numbers are circulating online.
Here's the proof: I ask ChatGPT “At what latency in milliseconds can I play e-drums with the Roland V71?”, and it answers “Independent measurements put its trigger-to-audio latency at approximately 1.7 ms (measured on the analog trigger inputs)”. "
∙
ChatGPT - LINK



* "If someone has a specific, reproducible objection to our approach, we want to hear it."

-->
I don't understand why you set the Scan Time to zero or a minimum value for your module latency measurements: Almost all users play e-drums with the default scan time (since it serves an important function, and it’s not for nothing that every manufacturer has preset the default scan time for a pad type exactly as they deem appropriate—and mesh pads have higher scan times than rubber pads due to how they work)—and the users simply don’t lower it, certainly not to zero or minimal (which makes no sense at all for an authentic trigger result). People want to know the latency for their actual playing situation, not a theoretical value that has nothing to do with the reality of playing. Without sufficient scan time, there can be no accurate velocity translation, let alone usable Positional Sensing.

If a VST setup with a Roland module has a total latency of 5 ms, then that’s naturally the case with the default scan time of 2 ms ( = the Roland Scan Time for most mesh pads). You could then reduce it by another 2 ms to achieve a total latency of 3 ms. However, as I said, setting it to the minimum doesn’t make sense.

And comparing the latency of modules—some of which do not allow any adjustment of the scan time at all (such as Efnote modules)—also makes no sense (especially if there is no indication that the scan time is not adjustable or could not be reduced).

(btw, aside from the important ”Scan Time”, trigger parameters like “Mask Time” and “Retrigger Cancel” have no effect on the module’s latency.)

So, my rule of thumb would be: always measure using the default scan time (which, for Roland modules with mesh pads, is 2 ms as a reference value) and, in that context, also specify the exact (default) scan time value for the module/pad type setup used for the measurement whenever possible (since that’s normally specified and set in milliseconds).

...

digitalDrummer mag: "How quickly can this module respond when trigger scanning isn't the limiting factor?"

--> my answer:
But that’s IMO exactly where the fallacy lies, because the scan process (with its scan time) is inevitably part of the module’s response. You could also ask: at what first minimum point of the piezo waveform does a module actually start to trigger?: We largely have no insight into this mandatory portion of the scan time at the minimum setting. For Roland modules, for example, the minimum setting is "0". That's for sure: it cannot really be 0. So how much 0 is "0" (or a minimum setting) anyway? Some modules have a positive value documented for their minimum scan time setting (e.g., ChatGPT tells me that the Alesis Strata Prime module starts at 0.4 ms). How much 0 is “0” in technical detail for each module? So, you cannot get 100% rid of the scan time for your kind of benchmark test - and the question will be: how much scan time is still left at a module's minimum setting. So there's some inconsistency here, especially when you specify exact decimal places in the millisecond range... Of course, you could say that we're now comparing the modules at their lowest scan-time setting. But then you'd have to add the following: “While it's largely unknown how much scan time each module still has at that point, we can at least turn it down that far—which, of course, is a completely irrelevant setting for authentic e-drumming.”

...