[PD] delay lines

Mathieu Bouchard matju at artengine.ca
Wed Apr 13 16:30:48 CEST 2011


On Wed, 13 Apr 2011, samuel rowe wrote:

> I had a read about wrap, and how it outputs the difference between the 
> input and nearest integer, like the output of 1.75 would be 0.25.

No, 1.75 becomes 0.75, while -1.75 becomes 0.25. The output of [wrap~] is 
the difference between input and the integer below or equal (the nearest 
of those that are not above).

> How would this replace two phasors?

the phasor used for writing the delay is to be reused by every reader to 
synchronise with the position that is currently considered to be the 
present.

> So one phasor would be used to read, then another one would trail 
> slightly behind writing?

Yes, or even a lot. If you're trying to use the whole table for that job, 
you will put the read-phase a bit _ahead_ of the write-phase, because if 
e.g. the read-phase is 97 % behind, it is also 3 % ahead, because it's a 
loop.

> oh, and after much reading I have discovered that although you can read 
> out of a delay line at any point, you can not drop in at a place and 
> write (ie.you cannot write at the 50msec point in a 200msec delay line) 
> so it looks like tables really are the way forward.

However, controlling the write-head is harder than controlling the 
read-head. There's a reason for which delwrite~/delread~ is done the way 
it is now. If you just move the write-head the way you move the read-head, 
it will skip samples during writing, which will cause your data to blend 
in weird ways with whatever was the older data.

It's complicated to stretch the data upon writing, especially in Pd, in 
which the normal way to stretch a live signal is to put it in a short 
delay line and read it with [vd~]. You can't write at variable rate with 
[delwrite~].

  _______________________________________________________________________
| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC


More information about the Pd-list mailing list