[PD] 0 length delay in delwrite~

Christof Ressi christof.ressi at gmx.at
Fri Dec 11 17:59:52 CET 2015


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" <porres at gmail.com>
An: "pd-list at lists.iem.at" <pd-list at lists.iem.at>
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_______________________________________________ Pd-list at lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list



More information about the Pd-list mailing list