[PD] 0 length delay in delwrite~

[Christof Ressi]

>> I'll keep saying it is a bug in the object, and that the object should be fixed in order to be consistent with its description. 

Or one could change the description to be consistent with the behaviour ;-). Once again, specifying the buffer size makes much more sense then giving a maximum delay time, because the latter one is dependend on the blocksize. As the various [delread~] objects can operate at different blocksizes (which can also change during runtime) the [delwrite~] object would need to keep track of this. In some cases, a change of blocksize for a single [delread~] would even need a memory reallocation for the whole delay line. So specifying the buffer size is the easiest way. 
[delread~] could, however, add 64 samples to the buffer, so that for 'regular' subpatches, the buffer size equals the maximum delay line (this is actually the behaviour of [vd~], which is not consistent with [delwrite~] by the way). Personally I think we should hide as little as possible from the user and just make it clear in the help-patch, that buffer size != max. delay time.

Actually I don't understand your example: if [delwrite~] and [delread~] are scheduled, specifying a maximum delay time of 0 is pointless. If you, however, want a simple block delay in a feedback loop, just use a pair of [send~] and [receive~].

Cheers


 
 

Gesendet: Freitag, 11. Dezember 2015 um 18:33 Uhr
Von: "Alexandre Torres Porres" <porres at gmail.com>
An: "Christof Ressi" <christof.ressi at gmx.at>
Cc: "pd-list at lists.iem.at" <pd-list at lists.iem.at>
Betreff: Re: [PD] 0 length delay in delwrite~

 
 
2015-12-11 14:59 GMT-02:00 Christof Ressi <christof.ressi at gmx.at>:This is related to the discussion we had some month ago about the maximum delay length in [delread~] and [vd~]. Remember: the arguement for [delwrite~] is actually the buffer size and not the maximum delay length (-> bug in the docs).
 
Yeah, and I'll keep saying it is a bug in the object, and that the object should be fixed in order to be consistent with its description. I have to say I'm sometimes surprised on how things that don't work properly are usually treated as harmless features even though they were clearly designed to work in a different and more convenient way ;)
 Apparantly, [delwrite] doesn't check for the minium buffer size and just acts weird if you set it to 0.
 
yeah, I'm pointing that out.
 
By the way, i should note that I've been using this (buffer size of "0") in  subpatch with a block size of 1 to performe single sample feedback. I then had always thought that the minimum delay size was "one block" size - which, by the way, seems to me like a clever design.
 
I tried to test it further and check it through, well, it's just really crazy.
 
 BTW: [delwrite~ 1.45125] + [delread~ 0] roughly equals a pair of [send~] and [receive~]
 
bug detected, btw ;)
 
cheers