Are scriptnode delays not accounting for block size and oversampling?
-
I created a simple comb filter to demonstrate this visually. It only works correctly with frame processing, that's when the frequency conversion is correct.
If blocksizes change, it's incorrect. The conversion stays the same, so it's the interpretation of Delay Time that's wrong. If you add oversampling to the mix, it messes things up even more: the output will also change as you change oversampling, but it will also be permanently shifted, so if you go oversampling none -> 2x -> none, you don't get the same output as before you touched oversampling.
If you then change the delay time, it recalculates itself and it's back to being correct at frame or incorrect by whatever factor in pow2 blocksizes.
I guess that the delay time doesn't have a sample rate change callback which forces the recalculation of the timing.
Can I get a sanity check on this situation before I add this to the 50 bug reports I already have open on GitHub?
-
@aaronventure Some questions about your question…
-
Does this phenomenon manifests visually, or is it audible as well?
-
Is it possible to use oversampling with a polyphonic ScriptNode Network?
-
-
@clevername27 said in Are scriptnode delays not accounting for block size and oversampling?:
Does this phenomenon manifests visually, or is it audible as well?
its audible of course, that's what the master analyser is showing. i opted for a comb filter so that i can demonstrate it here with a gif
@clevername27 said in Are scriptnode delays not accounting for block size and oversampling?:
Is it possible to use oversampling with a polyphonic ScriptNode Network?
why not?
-
@aaronventure said in Are scriptnode delays not accounting for block size and oversampling?:
@clevername27 said in Are scriptnode delays not accounting for block size and oversampling?:
Does this phenomenon manifests visually, or is it audible as well?
its audible of course, that's what the master analyser is showing. i opted for a comb filter so that i can demonstrate it here with a gif
Got ya. Is it localised at the high-end?
@clevername27 said in Are scriptnode delays not accounting for block size and oversampling?:
Is it possible to use oversampling with a polyphonic ScriptNode Network?
why not?
I get an error message saying it's not possible.
-
@clevername27 said in Are scriptnode delays not accounting for block size and oversampling?:
Got ya. Is it localised at the high-end?
The frequency display is just a manifestation of the delayed white noise being fed back through the delay.
You set the frequency with the delay time. The fft shows the harmonic series changing with blocksize and oversampling, which is a result of the delay time changing.
So if I set the delay time to 1ms, I would expect it to be 1ms at all sampling rates and block sizes.
-
@aaronventure Understood - thanks,
-
@clevername27 said in Are scriptnode delays not accounting for block size and oversampling?
- Is it possible to use oversampling with a polyphonic ScriptNode Network?
I don't believe it is possible due to the voice handling/polyphony architecture in hise.
-
@ally Thank you - appreciated the confirmation. @Christoph-Hart, how would you suggest approaching oversampling within this context?
-
@aaronventure It seems to me that oversampling should be a parameter of the network, and not a node. Same with block sizes. What do you think?
-
@clevername27 node format lets you decide exactly what you want to oversample or run with different block sizes, optimising the CPU footprint of the network
-
The delays are block size agnostic and just delay the signal by whatever value you set. The real question you should be asking (sorry for sounding pedantic here) is
Are scriptnode SEND / RECEIVE FEEDBACK ROUTINGS not accounting for block size and oversampling?
And the answer to this is: yup, they do not account for block sizes in the sense that every send / receive connection that goes against the natural signal flow (which is the case if the receive node comes before the send node in a feedback routing setup) introduces a latency of one processing chunk. So in order to make this as accurate as possible, you will need to use frame processing for that, then the delay time is off by one sample which is about as good as you can get in the digital domain.
I could add a node that you can connect between the delay time source and the delay time knob which sits next to the delay, reads out the current processing specs and subtracts that from the delay time before forwarding the parameter value to the delay time parameter, so that if the delay time should be 1000ms, it calculates how many milliseconds the current block size has (for 44kHz/256samples it's 5.8ms) and then sends 994.2ms to the delay) so that the total delay of the feedback network sums up to 1000).
However this will still not be 100% accurate because the first delay will then be faster than the following delays, which will be perfect, so it comes down to making a trade off between:
- CPU consumption
- First delay time accuracy
- Feedback delay time accuracy.
-
@Christoph-Hart If I do it with Faust, here's what I get:
it behaves fine on all blocksizes except frame,which I imagine is because Faust already does frame processing, so it manages to ignore whatever is happening above it.
It behaves fine on no OS, OS2x, OS4x, but on 8x and 16x it jumps up one octave and two octaves respectively.
