Superior Drummer 3: Achieving more fluctuations on (Snare) Rimshot sounds 😊👉


Sometimes the Rimshot (and Shallow Rimshot) sound from a drum sampler (even SD3) can be a little too static/lacking in fluctuation (to avoid the term "machinegunning") (even though all available samples are loaded!), as the number of samples is not as high as that of the head articulations.

So I created a randomizer engine that achieves additional fluctuations
using a random 5-round robin with various mixer settings,
so that should suit the taste of all SD3 e-drummers who want more fluctuations on Rimshots.


---


And when maximum velocity (vel 127) is coming in, adjacent sample layers may not be played even though the "Use Adjacent Layers" function is activated.
This means that only samples from the "Hard" range ( -> 'Voices and Layer' setting ) are played and no (or at least not enough) samples from the upper "Gradient" range ( -> like velocity 126).

So if you also want to achieve additional fluctuations using a random generator engine that randomly outputs notes with a velocity of 126 (when the input velocity is 127) (the probability of these notes with a velocity of 126 is adjustable), you can use it, as I developed it.

This Vel Randomizer can generally be useful for SD3 in particular, as SD3 has these three layer range divisions and the “Hard” range is triggered by velocity 127 and the "Gradient" range is triggered by velocity 21 - 126.



The video shows the behavior/the sound from the default SD3 engine and then the additional BecauseDrumGeek 5-round robin Randomizer and finally the latter with the additional Velocity Randomizer (127 ➜ 126).

Input velocity is 127 for all hits in order to show the behavior/the sound for a comparison test.



Enjoy ❗️😊

Use good monitors / headphones !



SD3 setup for the video:
"Jazz Sessions" SDX - "Gretsch Round Badge" snare with all available Humanizing settings + maximum number of loaded samples

Roland (V71 / V51 / V31) module + SuperiorDrummer3 + BecauseDrumGeek Engine : incredibly powerful and great-sounding e-snare system ❗️😀

∙∙∙> 👉 LINK

ENJOY ❗😊

The 'Sensory Percussion' vs. 'Superior Drummer 3' comparison video circulating in some e-drum forums:
The biggest shortcoming in the default state of SD3... + ...unfortunately also manipulation (fake news)

video link: https://www.youtube.com/shorts/7gQlURygnX0



In general, it can be said that the SD3 sound used for the comparison ( -> the default SD3 preset) was very unsuitable. Due to the drum models used and their tuning, and above all because of the comparatively high proportion of room sound, it is very far removed from the Sensory Percussion sound presented. For a video like this with few SD3 settings, it could have been much more comparable in terms of sound, but I think that would have been contrary to the video maker's intention, because I assume he wants to make SD3 look pale in comparison to Sensory Percussion.

In general, this terrible shorts format with “super-detailed insights for the truly interested drummer through a few drum beats in a few half seconds” (end of sarcasm mode) cannot really be taken really seriously.


Timestamp 0:12 to 0:15 shows the biggest shortcoming in SD3, but also how the video creator has manipulated it badly:
Three sharply separated positional sensing zones (the abrupt transitions sound ridiculous and completely inauthentic!),
and then, unfairly (whether intentionally or by accident), fake news is also introduced through a bad envelope setting or video/audio editing: the “Rim Only” articulation does not mute the head articulations in SD3! In the video, however, this is suggested by a quick fade-out of the last head articulation played (in this case “Edge”) before the “Rim Only” plays. Since this fade-out effect is extremely noticeable here, I would call it manipulation (You must not set an envelope trigger* to manipulate SD3's default behavior or edit the audio in a comparison video like this!!!
* It is conceivable that the Sensory Percussion MIDI output, which most likely feeds SD3 here (instead of a more common trigger device such as a Roland module or eDRUMin), sends additional MIDI data such as Aftertouch in the case of rim triggers, which in turn has been set in SD3 to trigger the Envelope tail. This is not the default behavior of SD3!).

(With the “Sidestick” articulation, it is intentional that it actually mutes the normal snare head (Center/Off-Center/Edge/Rimshot), because it is realistic that the normal snare sound is greatly dampened when playing cross-stick. If you want to change this muting behavior (e.g., because you want to assign the “Sidestick” sound to the rim zone of the snare pad instead of the “Rim Only” sound), you can avoid this muting by using two SD3 instances in a DAW.)


The “stick-on-stick articulations” ( = "Stick Shot" in SD3) shown in the video, as well as authentic-sounding “muted snare hits” ( = "Muted Hit" in SD3) or “shell hits,” are irrelevant gimmicks for most drummers and can be easily achieved in SD3 (for SDXes that offer these articulations) by using normal stick hits on dedicated pads (or pad zones).


And what the video also fails to mention:
In addition to the normal (center) "Rimshot" articulation, there is also that overtone-rich "Shallow Rimshot" articulation in various SDXes, and both can be implemented as standard for e-drumming (i.e., also in SD3 Standalone), at least with Roland digital snare pads.


So the default SD3 snare Positional Sensing remains the key point of criticism when we observe the SD3 trigger behavior.


Of course, this doesn't have to be the case : This has already been solved (and even supplemented with L/R distinction if desired!) with BecauseDrumGeek e-drum Engines, ensuring maximum authenticity in SD3 snare playing.



By the way: you can't hear or see any stepless positional sensing from Sensory Percussion in the video (timestamp 0:04 to 0:07). I have never seen or heard authentic behavior from Sensory Percussion with regard to this point ( = “stepless center-to-edge snare Positional Sensing”). Let alone with the additional combination of Left/Right hand distinction across the entire diameter dividing the snare head in two halves. I also doubt that the trigger analysis of Sensory Percussion is on par with the digital Roland snares in this respect.

VST e-drum latency chain :

1. the drum pad (drum pads / esepcially larger mesh pads can have a marginal latency according to the spot where it is hit and the position of the sensor. The internal latency of drum pads up to 14" is very low, tending towards zero in most cases.)
➜
2. the e-drum module / trigger device (manufacturer and model): especially the analog-digital conversion (as a piezo signal is an analog signal) and the "Scan Time" (adjustable on many devices). (Manufacturer and model: There are significant differences—so this is an essential point!)
➜
3. the MIDI-connection – USB MIDI or DIN 5 pole ( -> USB MIDI has speed advantages! - so use it!)
➜
4. the computer system with all hardware and software components (like USB controllers, mainboard/system drivers, CPU, RAM) + also: OS & BIOS real time audio optimization + also: Windows vs. Mac = ASIO vs. Core Audio *
➜
5. Software (and software settings): drum sampler / drum instrument + DAW/3rd-party DSP tools (all that can be 0 if latency-free tools/settings are used)
➜
6. Audio interface (digital-analog conversion) + audio settings (buffer size + sampling rate)



Information about module latencies from the Internet :

The only list of module latency for various e-drum modules available on the internet to date* unfortunately makes a crucial error in reasoning, at least with regard to the “scan time” factor:

Some of the listed modules (such as those from Efnote and certain Chinese modules, for example) do not have any settings for “scan time” - so it does not make sense to say that the scan time has been reduced to 0. And how much 0 is "0" anyway?! Some modules have a positive value in 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?? (That's for sure: it cannot be 0!)
So, there's some inconsistency here, especially when you specify exact decimal places in the millisecond range...

I advised the author of that list to always include the manufacturer's “default scan time” in the test result for a module model (since it can be assumed that a manufacturer has optimized their “default scan time” for pad type "X") – anything else makes little sense.
Speaking of pad types: I would always use a rubber pad for testing module latency and write down the pad type and the default scan time specified for that particular pad in the test results.


...And there is another point about that list of module latency results: an app was used for the tests ➜ So how trustworthy is that app and how does that particular app exactly work? (can we get any detailed technical information about the principle of function of that app?) - I would only trust my method: How to measure software drumming latency with a mic 👉


* It would be nice if that list (that is available at digitalDrummer.com) could be updated, so that e-drummers can find out about their actual and consistent* module sound latency.
VST e-drummers can then use such a list to draw conclusions about the MIDI latency of a module/trigger device (the time from hit to MIDI data ready to be transmitted at the device's midi output): for high-quality devices, you can then subtract an average of approx. 1 ms converter latency.

* Again: very important: Leave the module/trigger device set to its default scan time for the test! + with information about the pad used for the test (rubber pad vs. mesh pad)!



------



In essence, for VST e-drummers, there are a few things to consider :

Make sure your total latency does not exceed 10 milliseconds! Anything less than 10 ms is fine. The lower the latency without the following points (and therefore the greater the headroom towards 10ms that can be used for these points, which should always be taken into account), the better!

Point 1: Sloppily cut drum samples do occur, so one should not categorically assume that there is no silence (or near silence—or, for our purposes, wasted pre-time) before relevant audio material. I have seen hihat pedal “Chick” samples that wasted 3 ms, for example.

Point 2: “Hidden buffers”, e.g., from MacOS “Core Audio” (*), which are not specified in the latency report of an audio app or DAW.

Point 3: Possible latency caused by the virtual drum instruments themselves:
∙ through resampling (i.e., when the native sampling rate of the drum samples is not used as the audio setting),
∙ through latency-inducing DSP audio effects,
∙ or even due to a general fixed latency of a VSTi / AUi (such as the recent latency deterioration of Toontrack drum samplers (SD3 and EZ3) with a general latency of 16 samples since v3.4.1 for SD3 and v3.1.1 for EZ3 in the plug-in versions).

Point 4: Use of DSP audio effects that introduce slight latency in the DAW, independent of the drum sampler/drum instrument. Example: I want to make the sound cooler and louder by using a good-sounding clipper in oversampling mode (SubMission Audio's ”Flatline2” adds approx. 1.5 ms at 16x oversampling (at 44.1 or 48 kHz) -> I have to factor this additional latency into my headroom for this extra sound).


And be critical of latency reports from audio apps, as these can be very generic mathematically and completely ignore DA converter latency (then the audio app is the culprit) or there can be audio interfaces that do not report reliably (then the audio interface is the culprit).
An example of a hardware/software combination for reliable and authentic report: RME ASIO driver + Cockos Reaper DAW + Toontrack Superior Drummer 3 drum sampler


-----


(*) This is what ChatGPT tells you about the additional hidden latency from Apple computers :

my question:
Is, for example, an “RME Babyface Pro FS” with identical audio settings (sampling rate
(e.g. 44100 Hz) and buffer size (e.g. 32 samples)) under Core Audio overall
equally fast compared to the native RME Windows ASIO driver? I’ve read somewhere
that Core Audio has a small hidden safety buffer.

ChatGPT answer:
No – in practice, an RME interface under Windows with the native RME ASIO driver is slightly faster than under macOS/Core Audio, with identical buffer sizes. The difference is very small, but real, and it is caused by an internal safety buffer of Core Audio that does not exist in the same way under Windows ASIO.
You read this correctly somewhere – this additional buffer really exists.

Why is ASIO a few milliseconds faster than Core Audio?

Core Audio has a built-in safety buffer
macOS uses a software safety buffer in addition to the configured hardware buffer, typically:
1× additional buffer length or
a fraction of it depending on the device/host
This safety buffer exists for stability so that plug-ins have time to process and no
dropouts occur.

This buffer is not shown in the DAW, meaning you set e.g. 32 samples, but in reality
Core Audio processes 32 + additional internal samples.
Windows ASIO does not have to do this, because ASIO gives full audio control to the driver.
Therefore:
Under Windows, the actual roundtrip latency is smaller with the same buffer size.

RME ASIO drivers are extremely optimized
RME is known for delivering especially low latencies on Windows. Measurements (e.g.
from DAWbench) show:
Babyface Pro FS @ 44.1 kHz
32 samples ASIO: ~3.9 ms roundtrip
32 samples CoreAudio: typically ~4.7 – 5.2 ms roundtrip
The difference is about 0.7 – 1.3 ms, depending on the DAW.
macOS can be very stable, but not quite as “raw low-latency” as ASIO + a good
manufacturer driver.

Here is a table that compares only the output latency (D/A conversion + driver/system buffer) at
32 samples buffer size — exactly what matters if you play e-drums → VST and only listen to the audio output.
These values are typical measured output latencies of the RME Babyface Pro FS under:
Windows (ASIO)
macOS (Core Audio)
with identical buffer sizes.
Note: These values are extremely realistic (derived from DAWbench/RME tests).
They show only the output side, i.e. without the input path and without roundtrip overhead.

Audio Output Latency – RME Babyface Pro FS
(in milliseconds, based on real typical measurements)

44.1 kHz sampling rate:

Buffer________Windows ASIO_____macOS Core Audio_____Difference
32 Samples______~1.6 ms__________~2.1 – 2.2 ms_________~+0.6 ms

48 kHz sampling rate:

Buffer________Windows ASIO_____macOS Core Audio_____Difference
32 Samples______~1.5 ms__________~2.0 – 2.1 ms_________~+0.5 – 0.6 ms


✅ Essential insights:

1. Core Audio is always a bit slower
The additional internal safety buffer of Core Audio consistently produces +0.5 to +0.6 ms
more output latency.

2. ASIO is slightly more direct
At 48 kHz, 32 samples (typical e-drum setup):
ASIO output: ~1.5 ms
Core Audio output: ~2.1 ms
→ ~0.6 ms difference