Hallo, Kim Taylor hat gesagt: // Kim Taylor wrote:
... The time it takes logically is zero: The full block is written into the delay line immediatly (that is: at the same time, delread~ reads it, see below).
OK, But how can a full block be written to a delay line before it has happened? You say the time it takes is logically zero, but in order to write a full block of samples to a delayline, 64 bits of the input signal would have to have elapsed before this can happen surely?
For example: lets say there is an input signal to the explicitly defined sequence of delwrite~ - delread~ - output At t=0 the sample starts playing. Surely only until t=64 can a block be written by delwrite~ (immediately), and read (immediately) by delread~?
During one block of samples in Pd, *all* dsp-objects are calculated.
For the delwrite~/delread~ combination this means, that -- proper write->read ordering assumed -- first delwrite~ writes 64 samples into the delayline. But then, when delread~ reads, it starts reading at delay-line sample 0 and reads all 64 samples. These samples then get played by delread~. Here's ASCII art for [block~ 4]
"0 1 2 3" <= samples | [delwrite~ X] <= assumed to execute first, and in same block
[delread~ X] | "0 1 2 3" <= plays samples from above, in the same block
If you would have a different ordering, things change:
[delread~ X] | "-4 -3 -2 -1" <= these samples are from the previous block, because the samples "0 1 2 3" aren't in the delay line yet, they haven't happened yet.
"0 1 2 3" <= and these are the new samples | [delwrite~ X] <= now the new "0 1 2 3" get put into the delay line.
In this example you may see why with feedback you can never get a zero-delay:
"whatever"
|
| [delread~ X]
| /
|/
[delwrite~ X]
Basically there are two possibilities:
a) either read executes before write or
b) write exectues before read.
But b) is not compatible with Pd's architecture: If b) would be valid, delwrite~ would write its input samples ("whatever") into the delayline, then delread~ would read it and *immediatly* send new samples to delwrite~ again, through this invalidating the previous input to delwrite~. This is a loop in the dsp-chain, Pd will warn about this and stop execution.
So only a) is possible in Pd: first delread~ executes and reads, what was in the delay line before delwrite~ can write new samples into it.
Note that this is so *only* for *feedback* delay lines. Delay lines without feedback can have both orderings, see above.
In the end with feeback delay lines (or feedback throw~/catch~ pairs) you always get either one block delay or an illegal dsp-loop, so in practice you get one block delay.
To get the minimal delay possible, put both delwrite~ and delread~ into a *single* subpatch that you reblock to [block~ 1]. See attachement. Often also [block~ 2] or [block~ 8] or so is enough, it depends on how low you want to go. Be aware that small block sizes have high CPU load.
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__