[PD] Zero delay feedback, with settable send?
Frank Barknecht
fbar at footils.org
Sat May 12 23:57:37 CEST 2007
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__
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mindel.pd
Type: application/puredata
Size: 1531 bytes
Desc: not available
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20070512/fddbd182/attachment.bin>
More information about the Pd-list
mailing list