@TheOm: two additional questions:
1 - Is there any advantages to use FlowStone prims to calculate CountInt/Frac instead of doing it inside DSP code and output directly them?
2 - I think you have miss a important thing in
this explanation: it doesn't use CountInt and CountInt+1 as indexes for Read module, but respectively CountInt-1 and CountInt:
Code: Select all
pos1 = readposInt-1;
pos2 = pos1 + 1;
this have an impact using Input (thus step) lower than 1. Try to use (for example) Input (step) of 0.5:
First step, Input = 0.5:
CountInt = round(Input - 0.5)=0
CountFrac = Input - CountInt = 0.5
it reads 0.5 * sample
[-1] + 0.5 * sample
[0]Second step, Input = 0.5+0.5=1:
CountInt = round(1 - 0.5)=0
CountFrac = Input - CountInt = 1
it reads 0.0 * sample
[-1] + 1 * sample
[0]This could create strange artefacts, because if the first sample is 0, it's not a real "interpolation", but seems it "delay" the first sample. I've make a Ruby that show it:
- Immagine.png (17.08 KiB) Viewed 24416 times
Is that a normal behaviour of Linear Interpolation? Or due to the "trouble" with Round (that "force" this algorithm to use CountInt 1 based instead of 0) it will introduce this issue?
Anyway, having this code the whole process looks very better to understand and manage:
Code: Select all
foreach sample:
base = floor(index_pointer)
frac = index_pointer - base
out = in[base] * (1 - frac) + in[base + 1] * frac
index_pointer += speed
what we have in WavePlayer instead is this:
Code: Select all
foreach sample:
index_pointer += speed
base = round(index_pointer - 0.5)
frac = index_pointer - base
out = in[base-1] * (1 - frac) + in[base] * frac
due to how "round" acts (and I'm also not very sure if they produce exactly the same results).
Isn't any way to "emulate" a floor in DSP Code? (round to down)
Thanks for the explanation, very kind.
: round problems?