Actually, sorry- I thought I understood this but I've got a problem with this method
Considering the patch posted by Georg Holzmann (the same principle as http://crca.ucsd.edu/~msp/techniques/latest/book-html/node121.html)- Surely if the block size is default 64 samples, the delwrite atom will take at least 64 samples to write to the delay line... So the delread (next in sequence) cannot read out the contents of the delay line until AFTER this has happened? I don't understand how a minimum delay of 1 sample can be achieved (although I admit I have made it work in practice!!!)
Kim
Hallo, Kim Taylor hat gesagt: // Kim Taylor wrote:
Actually, sorry- I thought I understood this but I've got a problem with this method
Considering the patch posted by Georg Holzmann (the same principle as http://crca.ucsd.edu/~msp/techniques/latest/book-html/node121.html)- Surely if the block size is default 64 samples, the delwrite atom will take at least 64 samples to write to the delay line...
Not quite: The blocksize just specifies, how many samples [delwrite~] will write into the delay line during every block. 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).
So the delread (next in sequence) cannot read out the contents of the delay line until AFTER this has happened?
Yes, if you do the execution order right, the delread reads the delay buffer, after delwrite~ has written into it. That's the whole point of the order forcing! But as with the delwrite~, the reading happens "immediatly": delread~ will read a full block from the delay line, which means, it will read out exactly what delwrite~ has written into the buffer previously. As both writing and reading happens in the same sample block, you have no delay. In theory, that is.
I don't understand how a minimum delay of 1 sample can be achieved (although I admit I have made it work in practice!!!)
Actually I think, theoretically a minimum delay of zero samples could be achieved (although I admit I have not made it work in practice!!!) ;-)
More thought needed here ...
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
Hallo, Frank Barknecht hat gesagt: // Frank Barknecht wrote:
I don't understand how a minimum delay of 1 sample can be achieved (although I admit I have made it work in practice!!!)
Actually I think, theoretically a minimum delay of zero samples could be achieved (although I admit I have not made it work in practice!!!) ;-)
More thought needed here ...
Ah, made it: Actually it was the [vd~] interpolation, that was looking like it was interfering with the zero delay. Using [delread~] it's easier to visualize the zero sample delay by substraction.
See attachment.
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
Hallo!
Considering the patch posted by Georg Holzmann (the same principle as http://crca.ucsd.edu/~msp/techniques/latest/book-html/node121.html)- Surely if the block size is default 64 samples, the delwrite atom will take at least 64 samples to write to the delay line... So the delread (next in sequence) cannot read out the contents of the delay line until AFTER this has happened?
if the delread is computed after the delwrite you can read out the delay line immediately - so down to 1 sample delay.
See the patch G05.execution.order.pd !
LG Georg
Hallo, Georg Holzmann hat gesagt: // Georg Holzmann wrote:
if the delread is computed after the delwrite you can read out the delay line immediately - so down to 1 sample delay.
Make that "down to 0 samples delay", unless I'm wrong.
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
-
Frank Barknecht -
Georg Holzmann -
Kim Taylor