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