Dear list,
When starting Pd with the -nogui flag, [delread~] seems to ignore its float input (specifying the delay time in ms) and instead produce sounds which resemble a [delwrite~]/[delread~] loop at very short (one block of audio?) delay times.
Attached is a minimal example. (Attention, this will play straight to your soundcard at -20 dB for easy testing with -nogui!). To try, please start Pd first with and then without GUI.
I have observed this behaviour with Pd 0.41.4 under Debian GNU/Linux. Anyone else who ran into trouble with this or might know what's going on?
best, flo.H
=== BEGIN MINIMAL EXAMPLE ===
#N canvas 2 0 568 517 10; #X obj 132 359 dac~; #X obj 139 118 loadbang; #X obj 132 153 metro 1000; #X obj -23 386 loadbang; #X msg -23 441 ; pd dsp 1; #X obj -23 413 del 1000; #X obj 53 151 osc~ 220; #X obj 61 251 *~; #X msg 80 200 1 , 0 100; #X obj 80 225 line~; #X text 330 478 Florian Hollerweger , 2010; #X obj 132 330 *~; #X obj 205 294 dbtorms; #X obj 205 246 loadbang; #X msg 205 270 80; #X obj 162 220 delread~ line 350; #X obj -13 332 delwrite~ line 580; #X text 45 410 <- This [del 1000] is required due to another -nogui bug (audio will not work under -nogui without it); #X text -11 88 Tested with Pd 0.41.4 under Debian GNU/Linux; #X text 249 272 Master volume; #X obj 161 332 *~; #X msg 164 193 500; #X text -10 8 -nogui bug: This patch creates a test signal on the left channel once a second , which is delayed through [delwrite~] and [delread~] and then repeated on the right channel 500ms later. But when started with -nogui , the delay time of 500ms seems to be ignored.; #X connect 1 0 2 0; #X connect 1 0 21 0; #X connect 2 0 8 0; #X connect 3 0 5 0; #X connect 5 0 4 0; #X connect 6 0 7 0; #X connect 7 0 16 0; #X connect 7 0 11 0; #X connect 8 0 9 0; #X connect 9 0 7 1; #X connect 11 0 0 0; #X connect 12 0 11 1; #X connect 12 0 20 1; #X connect 13 0 14 0; #X connect 14 0 12 0; #X connect 15 0 20 0; #X connect 20 0 0 1; #X connect 21 0 15 0;
=== END MINIMAL EXAMPLE ===
Hey Flo,
IOhannes accused me of making this up when I posted it a week or so ago ;-) Thanks for posting a documented example. Yes it does seem like voodoo doesn't it?
D.
On 3/27/10 3:13 PM, Florian Hollerweger wrote:
Dear list,
When starting Pd with the -nogui flag, [delread~] seems to ignore its float input (specifying the delay time in ms) and instead produce sounds which resemble a [delwrite~]/[delread~] loop at very short (one block of audio?) delay times.
Attached is a minimal example. (Attention, this will play straight to your soundcard at -20 dB for easy testing with -nogui!). To try, please start Pd first with and then without GUI.
I have observed this behaviour with Pd 0.41.4 under Debian GNU/Linux. Anyone else who ran into trouble with this or might know what's going on?
best, flo.H
=== BEGIN MINIMAL EXAMPLE ===
#N canvas 2 0 568 517 10; #X obj 132 359 dac~; #X obj 139 118 loadbang; #X obj 132 153 metro 1000; #X obj -23 386 loadbang; #X msg -23 441 ; pd dsp 1; #X obj -23 413 del 1000; #X obj 53 151 osc~ 220; #X obj 61 251 *~; #X msg 80 200 1 , 0 100; #X obj 80 225 line~; #X text 330 478 Florian Hollerweger , 2010; #X obj 132 330 *~; #X obj 205 294 dbtorms; #X obj 205 246 loadbang; #X msg 205 270 80; #X obj 162 220 delread~ line 350; #X obj -13 332 delwrite~ line 580; #X text 45 410<- This [del 1000] is required due to another -nogui bug (audio will not work under -nogui without it); #X text -11 88 Tested with Pd 0.41.4 under Debian GNU/Linux; #X text 249 272 Master volume; #X obj 161 332 *~; #X msg 164 193 500; #X text -10 8 -nogui bug: This patch creates a test signal on the left channel once a second , which is delayed through [delwrite~] and [delread~] and then repeated on the right channel 500ms later. But when started with -nogui , the delay time of 500ms seems to be ignored.; #X connect 1 0 2 0; #X connect 1 0 21 0; #X connect 2 0 8 0; #X connect 3 0 5 0; #X connect 5 0 4 0; #X connect 6 0 7 0; #X connect 7 0 16 0; #X connect 7 0 11 0; #X connect 8 0 9 0; #X connect 9 0 7 1; #X connect 11 0 0 0; #X connect 12 0 11 1; #X connect 12 0 20 1; #X connect 13 0 14 0; #X connect 14 0 12 0; #X connect 15 0 20 0; #X connect 20 0 0 1; #X connect 21 0 15 0;
=== END MINIMAL EXAMPLE ===
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Hi Derek,
Derek Holzer wrote:
IOhannes accused me of making this up when I posted it a week or so ago ;-)
Gee, I swear I searched the archives first :-]
Yes it does seem like voodoo doesn't it?
Since the discovery of the infamous "no [loadbang]->[;pd dsp 1] under -nogui" bug (posted on this list by myself and others in the past), I do indeed consider -nogui to be the closest thing to voodoo which Pd has to offer.
More honestly though, it points to my personal lack of understanding of the GUI-DSP relation in Pd. Could someone with more insight than myself maybe comment on the origins of this weird DSP behavior of -nogui? Are there other potential traps? And: does someone maybe have ideas for a workaround for the [delread~] issue?
best, flo.H
On Sat, 2010-03-27 at 17:11 +0100, Derek Holzer wrote:
Hey Flo,
IOhannes accused me of making this up when I posted it a week or so ago ;-) Thanks for posting a documented example. Yes it does seem like voodoo doesn't it?
I also once stumbled across the problem [delread~] not being set properly on loadbang, when in -nogui mode. But I hadn't time to investigate further and I found another quick & dirty solution and forgot to report it.
Sorry, Derek, that I didn't back you up on the last post.
Roman
i also ran into this problem.
if i can remember correctly, the cause was something along the lines of:
the pd samplerate needs to be set before the delayline code is initiated. if pd is run in gui mode, then the gui initialization forces the order correctly.
however, when run in -nogui mode, the samplerate is set after the delayline code, and the calculation for the delayline is set with samplerate = 0
our hack was just to tweak the pd code to have a hardcoded samplerate.
matteo, by putting a [switch~] in each patch, it could possibly alleviate the problem, because i assume the [switch~] object forces samplerate to be recalculated.
On Sun, 2010-03-28 at 19:06 +0900, hard off wrote:
matteo, by putting a [switch~] in each patch, it could possibly alleviate the problem, because i assume the [switch~] object forces samplerate to be recalculated.
So having a [switch~] would solve all the -nogui initialization troubles? That is valuable to know. Thanks.
Roman
Hi,
hard off wrote:
however, when run in -nogui mode, the samplerate is set after the delayline code, and the calculation for the delayline is set with samplerate = 0
This sounds reasonable - thanks for illuminating this issue!
our hack was just to tweak the pd code to have a hardcoded samplerate.
I guess I should just browse the sources myself, but would it be easy enough for you to post the details of this hack to the list? I am sure that this would be a useful workaround for a number of people.
best, flo.H
Hi,
Roman Haefeli wrote:
So having a [switch~] would solve all the -nogui initialization troubles? That is valuable to know. Thanks.
I am afraid I cannot confirm this, as illustrated in the attached example. This is the same patch I posted yesterday, extended by a loadbanged [switch~].
Or am I missing something here? It would obviously be really cool to have a non-recompiling workaround for this.
By the way, it also does not help to delay the turning on of the [switch~], which I tried - knowing that loadbanged [;pd dsp 1( messages cause trouble under -nogui as well.
best, flo.H
#N canvas 2 0 555 550 10; #X obj 140 381 dac~; #X obj 147 140 loadbang; #X obj 140 175 metro 1000; #X obj -23 386 loadbang; #X obj -23 413 del 1000; #X obj 61 173 osc~ 220; #X obj 69 273 *~; #X msg 88 222 1 , 0 100; #X obj 88 247 line~; #X text 235 368 Florian Hollerweger , 2010; #X obj 140 352 *~; #X obj 213 316 dbtorms; #X obj 213 268 loadbang; #X msg 213 292 80; #X obj 170 242 delread~ line 350; #X obj -5 354 delwrite~ line 580; #X text -9 106 Tested with Pd 0.41.4 under Debian GNU/Linux; #X text 257 294 Master volume; #X obj 169 354 *~; #X msg 172 215 500; #X obj 63 499 switch~; #X text 45 408 <- HACK: [del 1000] also required due to audio initialization problems with -nogui; #X text -10 8 -nogui bug: This patch creates a test signal on the left channel once a second , which is delayed through [delwrite~] and [delread~] and then repeated on the right channel 500ms later. But when started with -nogui , the delay line is initialized before the samplerate is set , resulting in broken audio output.; #X msg -23 441 ; pd dsp 1; #X obj 63 448 loadbang; #X obj 63 475 tgl 15 0 empty empty empty 17 7 0 10 -262144 -1 -1 0 1; #X text 121 495 <- This does not seem to solve the -nogui audio init problems either (also not if [switch~] is turned on later); #X connect 1 0 2 0; #X connect 1 0 19 0; #X connect 2 0 7 0; #X connect 3 0 4 0; #X connect 4 0 23 0; #X connect 5 0 6 0; #X connect 6 0 15 0; #X connect 6 0 10 0; #X connect 7 0 8 0; #X connect 8 0 6 1; #X connect 10 0 0 0; #X connect 11 0 10 1; #X connect 11 0 18 1; #X connect 12 0 13 0; #X connect 13 0 11 0; #X connect 14 0 18 0; #X connect 18 0 0 1; #X connect 19 0 14 0; #X connect 24 0 25 0; #X connect 25 0 20 0;
So having a [switch~] would solve all the -nogui initialization troubles? That is valuable to know. Thanks.
that was just a guess. we actually got around it by modifying pd code.
florian, sorry i can not post the link, because it wasn't me who did the hack.
Hi,
FYI, your patch works with -nogui and winxp even without the [switch~]. Pd version 0.41.4-extended-20090509
Matteo Sisti Sette:
- _Every_ single abstraction that contains any dsp objects (or some
"ascendant" of it), always contains a [switch~], which is loadbanged to off, and later explicitly turned on when needed.
but if i understand correctly you would have to turn off [switch~] by a loadbang and turn it on with a delay. g.
Florian Hollerweger:
Hi,
Roman Haefeli wrote:
So having a [switch~] would solve all the -nogui initialization troubles? That is valuable to know. Thanks.
I am afraid I cannot confirm this, as illustrated in the attached example. This is the same patch I posted yesterday, extended by a loadbanged [switch~].
Or am I missing something here? It would obviously be really cool to have a non-recompiling workaround for this.
By the way, it also does not help to delay the turning on of the [switch~], which I tried - knowing that loadbanged [;pd dsp 1( messages cause trouble under -nogui as well.
best, flo.H
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Hi Georg, hi list,
Georg Werner wrote:
FYI, your patch works with -nogui and winxp even without the [switch~]. Pd version 0.41.4-extended-20090509
Thank you so much for this revealing contribution. I can indeed confirm that Windows XP seems to be free from the -nogui audio initialisation problems described earlier, including also the "[loadbang]->[;pd dsp 1(" problem.
This is reflected in the attached example "nogui_win.pd", which works for me with (and without) the -nogui flag under Windows XP, both with Pd extended 0.41.4 and Pd vanilla 0.42-5. Under Debian, however, it works only when *not* using -nogui, both with Pd vanilla 0.41.4 and vanilla 0.42-5.
but if i understand correctly you would have to turn off [switch~] by a loadbang and turn it on with a delay.
Thanks for pointing this out, but I cannot confirm this workaround to work under Debian. This is reflected in the attached example "nogui_linux.pd", which keeps failing to initialize audio correctly with Debian and -nogui (but plays fine under Windows XP and -nogui).
best, flo.H
#N canvas 176 88 564 588 10; #X obj 140 381 dac~; #X obj 147 140 loadbang; #X obj 140 175 metro 1000; #X obj -23 386 loadbang; #X obj -23 413 del 1000; #X obj 61 173 osc~ 220; #X obj 69 273 *~; #X msg 88 222 1 , 0 100; #X obj 88 247 line~; #X text 235 368 Florian Hollerweger , 2010; #X obj 140 352 *~; #X obj 213 316 dbtorms; #X obj 213 268 loadbang; #X msg 213 292 80; #X obj 170 242 delread~ line 350; #X obj -5 354 delwrite~ line 580; #X text 257 294 Master volume; #X obj 169 354 *~; #X msg 172 215 500; #X obj 63 499 switch~; #X text 45 408 <- HACK: [del 1000] also required due to audio initialization problems with -nogui; #X obj 63 448 loadbang; #X msg 63 475 0; #X obj 101 473 r switch; #X msg -23 441 ; pd dsp 1 ; switch 1; #X text -19 -41 -nogui bug: This patch creates a test signal on the left channel once a second , which is delayed through [delwrite~] and [delread~] and then repeated on the right channel 500ms later. -nogui bug: This patch creates a test signal on the left channel once a second , which is delayed through [delwrite~] and [delread~] and then repeated on the right channel 500ms later. The [switch~] object is supposed to serve as a workaround for the audio initialization problems with Pd (both vanilla 0.41.4 and vanilla 0.42-5) demonstrate at least under Debian GNU/Linux when started with the -nogui flag. However , the patch keeps failing for me under Debian and with -nogui , although it works fine under Windows XP and -nogui.; #X text 121 495 <- This does not seem to solve the -nogui audio init problems either (also not if the order of turning on dsp and switch is reversed in the message box on the left).; #X connect 1 0 2 0; #X connect 1 0 18 0; #X connect 2 0 7 0; #X connect 3 0 4 0; #X connect 4 0 24 0; #X connect 5 0 6 0; #X connect 6 0 15 0; #X connect 6 0 10 0; #X connect 7 0 8 0; #X connect 8 0 6 1; #X connect 10 0 0 0; #X connect 11 0 10 1; #X connect 11 0 17 1; #X connect 12 0 13 0; #X connect 13 0 11 0; #X connect 14 0 17 0; #X connect 17 0 0 1; #X connect 18 0 14 0; #X connect 21 0 22 0; #X connect 22 0 19 0; #X connect 23 0 19 0;
#N canvas 595 75 450 478 10; #X obj 140 381 dac~; #X obj 147 140 loadbang; #X obj 140 175 metro 1000; #X obj -23 386 loadbang; #X obj 61 173 osc~ 220; #X obj 69 273 *~; #X msg 88 222 1 , 0 100; #X obj 88 247 line~; #X text 235 368 Florian Hollerweger , 2010; #X obj 140 352 *~; #X obj 213 316 dbtorms; #X obj 213 268 loadbang; #X msg 213 292 80; #X obj 170 242 delread~ line 350; #X obj -5 354 delwrite~ line 580; #X text 257 294 Master volume; #X obj 169 354 *~; #X msg 172 215 500; #X msg -23 410 ; pd dsp 1; #X text -10 8 -nogui bug: This patch creates a test signal on the left channel once a second , which is delayed through [delwrite~] and [delread~] and then repeated on the right channel 500ms later. Under Debian (and Pd vanilla 0.41.4 or vanilla 0.42-5) , when started with -nogui , the delay line is initialized before the samplerate is set , resulting in broken audio output. Under Windows XP (and Pd vanilla 0.42-5 or extended 0.41.4) , the patch works fine with -nogui as well.; #X connect 1 0 2 0; #X connect 1 0 17 0; #X connect 2 0 6 0; #X connect 3 0 18 0; #X connect 4 0 5 0; #X connect 5 0 14 0; #X connect 5 0 9 0; #X connect 6 0 7 0; #X connect 7 0 5 1; #X connect 9 0 0 0; #X connect 10 0 9 1; #X connect 10 0 16 1; #X connect 11 0 12 0; #X connect 12 0 10 0; #X connect 13 0 16 0; #X connect 16 0 0 1; #X connect 17 0 13 0;
hi
On 2010-03-27 17:11, Derek Holzer wrote:
Hey Flo,
IOhannes accused me of making this up when I posted it a week or so ago ;-) Thanks for posting a documented example. Yes it does seem like voodoo doesn't it?
i haven't tried the patch yet, but indeed there seems to be a problem, thanks for providing a patch :-) i guess that roman's explanation is quite precise.
one thing you you try, is to explicitely set the samplerate at startup: try "pd -nogui -r 44100"
fmasdr IOhannes
PS: seems like me trick doesn't work PPS: could you post this to the bugtracker
Hi,
IOhannes m zmoelnig wrote:
one thing you you try, is to explicitely set the samplerate at startup: try "pd -nogui -r 44100"
I remember this trick having been suggested also for the "no [loadbang]->[;pd dsp 1( under -nogui" problem. As there, it does not work for me in the current situation.
In other words, the "nogui_linux.pd" patch from my last post (http://lists.puredata.info/pipermail/pd-list/attachments/20100328/bc29ef25/a...) still does not work under Debian and Pd 0.41.4, even when called with pd -nogui -r 44100
PPS: could you post this to the bugtracker
Will do.
best, flo.H
I have this problem too... I'm baffled for the moment but want to figure it out and fix it :)
Miller On Mon, Mar 29, 2010 at 10:39:44AM +0100, Florian Hollerweger wrote:
Hi,
IOhannes m zmoelnig wrote:
one thing you you try, is to explicitely set the samplerate at startup: try "pd -nogui -r 44100"
I remember this trick having been suggested also for the "no [loadbang]->[;pd dsp 1( under -nogui" problem. As there, it does not work for me in the current situation.
In other words, the "nogui_linux.pd" patch from my last post (http://lists.puredata.info/pipermail/pd-list/attachments/20100328/bc29ef25/a...) still does not work under Debian and Pd 0.41.4, even when called with pd -nogui -r 44100
PPS: could you post this to the bugtracker
Will do.
best, flo.H
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Hi,
Miller Puckette wrote:
I have this problem too... I'm baffled for the moment but want to figure it out and fix it :)
Great. By the way, I have followed IOhannes' recommendation and posted the issue to the bugtracker (#2978457), including the latest version of the example patch and a description of the problem which incorporates all contributions (suggested workarounds, etc.) which appeared in this thread so far.
best, flo.H