running mac os 10.4, and the latest version of vanilla pd with -nogui, the attached patch does not work how it should.
the patch is a simple phasor~ ping sound, run through a [delread~] / [delwrite~] delayline. with gui turned on, it works as expected, making a feedback echo,
but with -the nogui option enabled, the delayline is just making a small delay (my guess is one block)
is this a known issue? are there other known issues with running -nogui on mac, or in general? this is the first definite trouble we have isolated, but i think we might have some other issues too.
hard off wrote:
running mac os 10.4, and the latest version of vanilla pd with -nogui, the attached patch does not work how it should.
which is the "latest" version of Pd-vanilla for you? 0.42-5? (i guess it would be good to always use "full" version numbers, so that they keep a meaning in the archive)
the patch is a simple phasor~ ping sound, run through a [delread~] / [delwrite~] delayline. with gui turned on, it works as expected, making a feedback echo,
but with -the nogui option enabled, the delayline is just making a small delay (my guess is one block)
i can confirm this with 0.41-4 and 0.42-4 on linux.
i don't have any explanation at hand.
fgmasdr IOhannes
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=55...)
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.
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;
yeah sorry, i tested on 0.42-5, and also on 0.41-4 and got the same thing.
your help on this issue is really appreciated iohannes, thanks.
would it be possible for us to modify the source code (eg d_delay.c) to set a non-variable samplerate? in our case, the samplerate will always be 22050hz.
or is it not as simple as i imagine?
-
hard off -
IOhannes m zmoelnig