Re: [PD] -nogui troubles on mac

[IOhannes m zmoelnig]

IOhannes m zmoelnig wrote:

hard off wrote:

but with -the nogui option enabled, the delayline is just making a small
delay (my guess is one block)

here it seems to be more than one block: something like 1.63 ms

i can confirm this with 0.41-4 and 0.42-4 on linux.

i don't have any explanation at hand.

the problem seems to be that the audio-subsystem is not fully initialized yet (see a bug-report by claude on a simliar issue: https://sourceforge.net/tracker/?func=detail&aid=2724318&group_id=55736&atid=478070)

fmgad.sr.
IOhannes

#N canvas 217 68 1047 555 10;
#X obj 166 127 +~;
#X obj 167 375 +~;
#X obj 161 447 dac~;
#X msg 542 60 \; pd dsp 1;
#X obj 536 -22 loadbang;
#X obj 234 303 *~ 0.8;
#X obj 232 265 delread~ dl 150;
#X obj 541 20 delay 1000;
#X msg 509 163 \; pd dsp 0;
#X floatatom 396 296 5 0 0 0 - - -;
#X floatatom 239 233 5 0 0 0 - - -;
#X obj 384 207 netreceive 7777 1;
#X obj 401 260 print deltime;
#N canvas 0 0 450 300 delwrite~ 0;
#X obj 47 46 inlet~;
#X obj 100 100 delwrite~ dl 250;
#X connect 0 0 1 0;
#X restore 244 122 pd delwrite~;
#X obj 635 180 s pd-delwrite~;
#X msg 644 139 obj 100 100 delwrite~ dl 250 \, connect 0 0 1 0;
#X obj 545 41 t b b;
#X obj 328 -8 phasor~ -1;
#X obj 327 15 *~;
#X obj 327 35 *~;
#X obj 166 93 *~;
#X obj 166 -3 phasor~ 10000;
#X obj 165 43 *~ 0.5;
#X obj 326 57 *~;
#X obj 326 77 *~;
#X connect 0 0 1 0;
#X connect 0 0 13 0;
#X connect 1 0 2 0;
#X connect 1 0 2 1;
#X connect 4 0 7 0;
#X connect 5 0 1 0;
#X connect 5 0 13 0;
#X connect 6 0 5 0;
#X connect 7 0 16 0;
#X connect 9 0 5 1;
#X connect 10 0 6 0;
#X connect 10 0 12 0;
#X connect 11 0 10 0;
#X connect 15 0 14 0;
#X connect 16 0 3 0;
#X connect 16 1 15 0;
#X connect 17 0 18 0;
#X connect 17 0 18 1;
#X connect 18 0 19 0;
#X connect 18 0 19 1;
#X connect 19 0 23 0;
#X connect 19 0 23 1;
#X connect 20 0 0 0;
#X connect 21 0 22 0;
#X connect 22 0 20 0;
#X connect 23 0 24 0;
#X connect 23 0 24 1;
#X connect 24 0 20 1;

thus [delwrite~] does not know the real samplerate at the time of creation and therefore computes the delay-buffer wrongly (way too short) since the delay buffer is so short, you can send [delread~] any delaytime, it will not really change anything. one ugly workaround for now is to dynamically create the [delwrite~] at a time where the samplerate has already settled.

smime.p7s
Description: S/MIME Cryptographic Signature

_______________________________________________
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list