>> 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" <[email protected]> An: "Christof Ressi" <[email protected]> Cc: "[email protected]" <[email protected]> Betreff: Re: [PD] 0 length delay in delwrite~ 2015-12-11 14:59 GMT-02:00 Christof Ressi <[email protected]>: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 _______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
