Page 1 of 1
A study of eDRUMin internal latency
Posted: Wed Dec 30, 2020 3:47 am
by Rob
I spent some time this morning doing performance measurements. I measured the time from the end of scanning until the a MIDI event is sent out. This gives a very accurate measurement of how long it takes eDRUMin to do all the processing for various pad types and features. I thought I would post the results here for anyone who's interested in that sort of thing. The lower numbers for ED10 are the result of its processor's internal floating point calculator which provides about 20x performance when working with decimals.
Note the numbers are in microseconds, not milliseconds.
- eDRUMin_internal_latency.png (17.56 KiB) Viewed 1006 times
Re: A study of eDRUMin internal latency
Posted: Wed Dec 30, 2020 3:55 am
by perceval
The cold front keeping you inside this morning?
Wow,,, the huge bump in piezo/piezo processing on the ED4.
There are ms hunters on VDrums that would go nuts....
Yet, when I play using the ED4, it doesn't feel "sluggish" as the numbers would indicate
Re: A study of eDRUMin internal latency
Posted: Wed Dec 30, 2020 4:02 am
by Rob
Those numbers are microseconds, not milliseconds. There are 1000 microseconds in 1 ms.
An ED4 processing a dual zone pad with hotspot suppression, positional sensing, and velocity curve is going to need less than 0.1ms to do all the math and spit out a MIDI note.
Re: A study of eDRUMin internal latency
Posted: Wed Dec 30, 2020 7:11 am
by perceval
Ha ha! My brain is frozen from that cold front this morning!
Indeed... not milli but microseconds.... Sorry!
So, the rest is adding the scanning, which ranges usually between 5ms (milli) to 11ms, depending on the pad used and it's quality of signal, then we have "module" latency, and then adding the computer time, VST and audio interface, latency to get the real life value.
Re: A study of eDRUMin internal latency
Posted: Wed Dec 30, 2020 7:28 am
by Rob
Indeed it's chilly! Scanning doesn't include the hold time, so 2.5 ms to 3.5 ms for 90% of drums. For real world latency, this thread holds more useful information:
viewtopic.php?f=29&t=485&p=1941&hilit=latency#p1941
As I code away at version 1.4, I was curious how much extra latency those various features add, and it turns that the extra processing is insignificant.
Re: A study of eDRUMin internal latency
Posted: Thu Dec 31, 2020 12:52 am
by MisterE
Rob wrote:Indeed it's chilly! Scanning doesn't include the hold time, so 2.5 ms to 3.5 ms for 90% of drums. For real world latency, this thread holds more useful information:
viewtopic.php?f=29&t=485&p=1941&hilit=latency#p1941
As I code away at version 1.4, I was curious how much extra latency those various features add, and it turns that the extra processing is insignificant.
I'm sure glad a few microseconds won't slow down your coding process, Rob!
