On Tuesday, 28 April 2015 at 15:49:53 UTC, ponce wrote:
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.
This is what i meant by z-transform, maybe a confusion in the
name, but it think to "the fact that the previous sample value
must be stored for processing the next one"...
If you have only a filter it can be batch-processed but if the
the filter is plugged to a delay line itself pluged to a SSB
frequency shifter whose itself has a feedback bus going to...well
it cant be buffered anymore.
In video game, they play wavetables and eventually the output is
passed in a binaural spatiializer or a reverb unit...though it's
still need sample rate info for re-sampling and maybe dithering
depending on the sample bit-depth of the samples frames.
