I have had success using throw~ and catch~, as the destination bus can be changed by setting throw~, BUT- throw and catch use a minimum block size of 64.
Hm? They don't, unless you do feedbacks, but then everyhting~ in Pd has a delay of one block.
How true, I must have overlooked this... Fantastic news Thanks
K
Hallo, Kim Taylor hat gesagt: // Kim Taylor wrote:
I have had success using throw~ and catch~, as the destination bus can be changed by setting throw~, BUT- throw and catch use a minimum block size of 64.
Hm? They don't, unless you do feedbacks, but then everyhting~ in Pd has a delay of one block.
How true, I must have overlooked this...
It's one of the tricky things to get right in Pd. ;)
If you really want to make sure not to pick up any unwanted delays you need to use the double-subpatch technique described in Miller's book, as the block-delay of direct connections depends on the order in which you made the connections, and that's to fragile: editing can change the order without you noticing it.
Frank Barknecht _ ______footils.org_ __goto10.org__
Hallo!
If you really want to make sure not to pick up any unwanted delays you need to use the double-subpatch technique described in Miller's book, as the block-delay of direct connections depends on the order in which you made the connections, and that's to fragile: editing can change the order without you noticing it.
So you need order forcing (see attached patch). You can get delays down to 1 sample with that method AFAIK.
LG Georg
#N canvas 546 262 448 422 10; #X obj 46 181 inlet~ signal; #X obj 146 307 sig~; #X obj 46 363 outlet~; #N canvas 0 0 450 212 delay-writer 0; #X obj 22 27 inlet~; #X obj 52 87 delwrite~ $0-delline1 2000; #X obj 116 113 delwrite~ $0-delline2 2000; #X obj 22 159 outlet~; #X connect 0 0 1 0; #X connect 0 0 2 0; #X connect 0 0 3 0; #X restore 46 227 pd delay-writer; #N canvas 0 0 450 300 delay-reader 0; #X obj 38 165 vd~ $0-delline1; #X obj 38 191 outlet~; #X obj 38 139 inlet~; #X obj 35 39 inlet~; #X text 34 61 dummy; #X text 34 75 (to force execution order !); #X connect 0 0 1 0; #X connect 2 0 0 0; #X restore 46 335 pd delay-reader; #X text 55 266 <- needed for right execution order !; #X obj 180 181 inlet delay; #X text 15 20 exact-delay~; #X text 15 90 This patch is able to get a delay down to 1 sample because of execution order forcing !; #X text 15 48 in1: the signal; #X text 15 62 in2: delay time in ms; #X text 255 372 Georg Holzmann , 2007; #X connect 0 0 3 0; #X connect 1 0 4 1; #X connect 3 0 4 0; #X connect 4 0 2 0; #X connect 6 0 1 0;
Frank Barknecht wrote:
as the block-delay of direct connections depends on the order in which you made the connections, and that's to fragile: editing can change the order without you noticing it.
actually to be accurate it is not the order in which you made the connections but the order in which you created the delread and delwrite objects. If you want to have a 0 delay make sure to create the delread before the delwrite. or use the subpatch hack. marius.
Hallo, marius schebella hat gesagt: // marius schebella wrote:
Frank Barknecht wrote:
as the block-delay of direct connections depends on the order in which you made the connections, and that's to fragile: editing can change the order without you noticing it.
actually to be accurate it is not the order in which you made the connections but the order in which you created the delread and delwrite objects. If you want to have a 0 delay make sure to create the delread before the delwrite. or use the subpatch hack.
Ah, yes, thanks for the correction.
Frank Barknecht _ ______footils.org_ __goto10.org__