On Tuesday, 28 April 2015 at 15:11:16 UTC, Stincky gecko wrote:
On Tuesday, 28 April 2015 at 15:01:23 UTC, ponce wrote:
On Tuesday, 28 April 2015 at 15:00:18 UTC, ponce wrote:
- clearing the state (setting delaylines to 0)
- separate channels that can be stored interleaved or not.
Samples would be indexed by time and channel index. I feel
like samplerate can be left out of the equation, it will
almost always be a runtime value.
- and more importantly, batch processing instead of sample per
sample like I do now in dplug
in d plug sample by sample processing is justified because of
the z-transform, while in video games you just basically play
some wavetables.
Even hugely stateful things can benefit of buffering.
For example, biquad filters have an internal loop that looks like
(pseudo-code):
for each sample
{
input <- input-signal[n]
output <- a0 * input + a1 * x[0] + a2 * x[1] - a3 * y[0]
- a4 * y[1]
// update state of filter
x[1] <- x[0]
x[0] <- input
y[1] <- y[0]
y[0] <- output;
}
It cannot be parallelized because it's too stateful.
BUT by unrolling it by 3, SIMD can be used and benefit such a
loop.
