[PD] Zero delay feedback, with settable send?

Frank Barknecht fbar at footils.org
Sat May 12 23:57:37 CEST 2007

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

 | [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.

 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