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). The maximum delay time is the buffer size minus 1 block size. Therefore [delwrite~]'s argument has to be at least one block length in ms (1.45125 ms for 44.1 Khz), otherwise it doesn't make sense (there's no space for your signal to be written to). Apparantly, [delwrite] doesn't check for the minium buffer size and just acts weird if you set it to 0.
BTW: [delwrite~ 1.45125] + [delread~ 0] roughly equals a pair of [send~] and [receive~] Gesendet: Freitag, 11. Dezember 2015 um 17:26 Uhr Von: "Alexandre Torres Porres" <[email protected]> An: "[email protected]" <[email protected]> Betreff: [PD] 0 length delay in delwrite~ hi, I'm checking that if you put a 0 length delay in delwrite~ you still have some buffer what's up with that? and how does it work? how big is it when you don't define it? I always get a minimum dealy even with order forcing (and different values depending on extended orvanilla), it seems the delay needs to be at least the block size to work properly moreover, I can't have an order forcing thanks_______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list _______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
