Hi,
the help of delread4~ states the "delay time is at least one sample", but it seems the lower limit is one block (and the lowest blocksize I can use on linux seems to be 64 samples). I assume this is related to the dsp scheduling order introducing one sample block latency.
The pd sources (d_delay.c) suggests to me that latency compensation in the signal chain is taken care of, but I'm hitting a wall on my machine. For a flanger-like application this means the highest obtainable frequency here is 689 Hz at 44100 samplerate, which limits its usability.
Attached is a patch to demonstrate the highest obtainable frequency (here it is somewhere around f'' or Midi 78).
Can someone check whether this is a general problem or it is only on my machine? I tested with newest pd (0.52) and 0.50.
-- Orm
On 03.04.2022 20:01, Orm Finnendahl wrote:
Hi,
the help of delread4~ states the "delay time is at least one sample", but it seems the lower limit is one block (and the lowest blocksize I can use on linux seems to be 64 samples). I assume this is related to the dsp scheduling order introducing one sample block latency.
If the delread~ is scheduled /before /the delwrite~, there will be one block of additional delay. You can force the delread~ to be scheduled /after /the delwrite~ by putting the two objects in different subpatches and connect them with dummy signals, as explained in 3.audio.examples/G05.execution.order.pd.
However, once you add a feedback path - as you do in your patch -, this trick doesn't work because in the digital domain, feedback without delay is simply not possible. The only thing you can do is decrease the block size. This is explained in 3.audio.examples/G04.control.blocksize.pd.
Christof
Hi Christof, Max,
thanks, makes sense. I'll use the delreadsinc~ version as it indeed is used for waveguides.
-- Orm
Am Sonntag, den 03. April 2022 um 21:34:46 Uhr (+0200) schrieb Christof Ressi:
On 03.04.2022 20:01, Orm Finnendahl wrote:
Hi,
the help of delread4~ states the "delay time is at least one sample", but it seems the lower limit is one block (and the lowest blocksize I can use on linux seems to be 64 samples). I assume this is related to the dsp scheduling order introducing one sample block latency.
If the delread~ is scheduled /before /the delwrite~, there will be one block of additional delay. You can force the delread~ to be scheduled /after /the delwrite~ by putting the two objects in different subpatches and connect them with dummy signals, as explained in 3.audio.examples/G05.execution.order.pd.
However, once you add a feedback path - as you do in your patch -, this trick doesn't work because in the digital domain, feedback without delay is simply not possible. The only thing you can do is decrease the block size. This is explained in 3.audio.examples/G04.control.blocksize.pd.
Christof
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
if you set the delay time to 0.1 in your patch, delreadsinc~ from https://github.com/chairaudio/pure-data/tree/feature/delreadsinc will make a huge difference.
max
On 03.04.22 20:01, Orm Finnendahl wrote:
Hi,
the help of delread4~ states the "delay time is at least one sample", but it seems the lower limit is one block (and the lowest blocksize I can use on linux seems to be 64 samples). I assume this is related to the dsp scheduling order introducing one sample block latency.
The pd sources (d_delay.c) suggests to me that latency compensation in the signal chain is taken care of, but I'm hitting a wall on my machine. For a flanger-like application this means the highest obtainable frequency here is 689 Hz at 44100 samplerate, which limits its usability.
Attached is a patch to demonstrate the highest obtainable frequency (here it is somewhere around f'' or Midi 78).
Can someone check whether this is a general problem or it is only on my machine? I tested with newest pd (0.52) and 0.50.
-- Orm
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
-
Christof Ressi -
Max -
Orm Finnendahl