SlamInsert

The layout connects the bus's own pre-insert signal here. Any low-cut ahead of the tap has to be bypassed or the effect disappears exactly when the player is in the air: the lift is a high-pass, so a slam taken from after it would be boosting a shelf on a band that had already been removed, and would be at its weakest where half the gates are taken.

The wet arm's shaper is oversampled, and an oversampler is a pair of resampling filters that delay what passes by an amount no specification fixes — measured 2026-09-19, 192 samples at 4x in Chrome and 128 in node-web-audio-api. With nothing on the other side waiting for it, a strike combed against the very score it was blended into: 1.6 dB of a full strike cancelled in Chrome, and a different comb on each implementation. So this is the same oversampling around a curve that changes nothing, and it is as late as the wet arm wherever it runs, with nothing measured and nothing looked up.

What it costs. The bus it heads is late by that latency, about four milliseconds, against every bus it does not head; it is band-limited as the oversampler band-limits, which is −98 dB of difference from a plain delay up to 20 kHz, measured in Chrome; and the bus pays for a second oversampler, about 7 ms of render per two seconds of mono there. What would make it wrong: an implementation whose oversampling latency depends on the curve, or a shaper that reports its latency, which would let a plain DelayNode do this for less.