Re: [PD] Weird [delread~] behavior under -nogui

[Florian Hollerweger]

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

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

Re: [PD] Weird [delread~] behavior under -nogui

[Miller Puckette]

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/attachment.asc)
> 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

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

Re: [PD] Weird [delread~] behavior under -nogui

[Florian Hollerweger]

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/attachment.asc)
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

Re: [PD] Weird [delread~] behavior under -nogui

[IOhannes m zmoelnig]

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



smime.p7s
Description: S/MIME Cryptographic Signature
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] Weird [delread~] behavior under -nogui

[Florian Hollerweger]

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;
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] Weird [delread~] behavior under -nogui

[Georg Werner]

Hi,

FYI, your patch works with -nogui and winxp even without the [switch~].
Pd version 0.41.4-extended-20090509

Matteo Sisti Sette:
> 3) _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


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

Re: [PD] Weird [delread~] behavior under -nogui

[hard off]

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.
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] Weird [delread~] behavior under -nogui

[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
#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;
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] Weird [delread~] behavior under -nogui

[Florian Hollerweger]

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

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

Re: [PD] Weird [delread~] behavior under -nogui

[Roman Haefeli]

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


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

Re: [PD] Weird [delread~] behavior under -nogui

[hard off]

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.
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] Weird [delread~] behavior under -nogui

[hard off]

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.
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] Weird [delread~] behavior under -nogui

[Roman Haefeli]

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


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

Re: [PD] Weird [delread~] behavior under -nogui

[Matteo Sisti Sette]

Somebody wrote:

>> The way I remember it, anything to do with tables or other allocated
>> memory can break with -nogui. [tabwrite~], [tabread~], [delwrite~],
>> [delread~], [vd~] etc etc

I'm very curious about this issue and quite surprised, since I have been 
using -nogui for a long time, with quite a lot of tables and 
[tabread/write~]s, and also some [delread/write~]s (no vd~ though), and 
I never experienced any such issue...


May any of the following things be the reason why I don't experience 
this issue?


1) I work under Windows
2) The patch running in -nogui has almost no gui objects (maybe a couple 
of numberboxes and toggles or so) and no gop-enabled subpatch or 
abstraction at all.
3) _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.
4) I also turn dsp off and on with [; pd dsp 1/0( messages. I think dsp 
is always turned off and on at least once before "showtime".
5) All is controlled via [netreceive] from another patch, running on 
another instance of Pd, which has gui and doesn't process any sound (it 
is a "gui-engine" architecture)



I guess (3) is the best candidate...?

None of the mentioned things was done with the aim of avoiding this 
issue since I didn't know anything about it...


--
Matteo Sisti Sette
matteosistise...@gmail.com
http://www.matteosistisette.com

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

Re: [PD] Weird [delread~] behavior under -nogui

[Florian Hollerweger]

Hi Matt,

Matt Barber wrote:
> what I was suggesting was that the -nogui might be
> interfering with the implementation of the delay lines themselves, not
> specifically with [delread~].

I agree, the [delread~] behavior under -nogui seems to be the/a symptom
of a cause which is probably located at a lower level than [delread~]
itself.

best,
flo.H

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

Re: [PD] Weird [delread~] behavior under -nogui

[Matt Barber]

Right -- what I was suggesting was that the -nogui might be
interfering with the implementation of the delay lines themselves, not
specifically with [delread~].

Matt

On Sat, Mar 27, 2010 at 2:19 PM, Florian Hollerweger  wrote:
> Hi Matt,
>
> Matt Barber wrote:
>> Are we sure this is a problem with [delread~]?
>
> I would actually argue it's primarily a problem with -nogui rather than
> with [delread~].
>
> I have been snooping around the archives, since Derek pointed out that
> he posted the same issue to the list about a week ago, and it seems he
> observed the same problem also with other objects under -nogui:
>
>> The way I remember it, anything to do with tables or other allocated
>> memory can break with -nogui. [tabwrite~], [tabread~], [delwrite~],
>> [delread~], [vd~] etc etc
>
> In response, IOhannes suggested that
>
>> there are known problems initializing the sound system in nogui-mode.
>
> I was not suggesting that [delread~] was buggy, but wanted to learn more
> about the nature of these -nogui audio initialization problems.
>
> best,
> flo.H
>

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

Re: [PD] Weird [delread~] behavior under -nogui

[Matt Barber]

Are we sure this is a problem with [delread~]?  There's a related bug
where if you open a patch which has delays at one sample rate, if you
then change the sample rate in the preferences it won't reallocate the
delay buffers, so if you increase the sample rate, you're left with
shorter delay lines (they're just as long in samples but shorter in
milliseconds).  When it happens it feels like a [delread~] problem
since that's what you're controlling, but really it's in the
implementation of the delay buffer.  This may have been fixed in
recent versions -- I have been keeping at 0.40 for a while now, so I
don't know for sure.

Matt

>
> 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
>>
>
> --
> ::: derek holzer ::: http://macumbista.net :::
> ---Oblique Strategy # 112:
> "Magnify the most difficult details"

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

Re: [PD] Weird [delread~] behavior under -nogui

[Florian Hollerweger]

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

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

Re: [PD] Weird [delread~] behavior under -nogui

[Derek Holzer]

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



--
::: derek holzer ::: http://macumbista.net :::
---Oblique Strategy # 112:
"Magnify the most difficult details"

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

[PD] Weird [delread~] behavior under -nogui

[Florian Hollerweger]

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