Hey Chrissie,

That would be awesome if you fixed it! Its been discussed before, perhaps on pd-dev. I think matju once outlined what the cause was, but I can't remember specifics.

.hc

On Apr 10, 2012, at 11:11 AM, Chrissie Caulfield wrote:

Hi all,

I've been scouring the lists for a solution to this but none of them seem to work for me. Almost all non-trivial patches produce no sound with the -nogui flag, even with the delayed startup or the workaround_loader.pd that was posted here some time ago.

I know very little about the pd code but I'm a competent C professional programmer and really want to fix this. Does anyone have any ideas where I might start to look or is it still 'voodoo'? ;-)

I'm using pd-extended from git & externals from svn, checked out this morning.

I've managed to make this trivial patch that reproduces the problem (and includes the startup delay). I don't know why polygate~ does show the problem where hip~ and friends don't but I'm hoping it's a clue!

So, does anyone have any (even vague) ideas of where to start before I start randomly digging?

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

"We have nothing to fear from love and commitment." - New York Senator Diane Savino, trying to convince the NY Senate to pass a gay marriage bill

On 10/04/12 16:11, Chrissie Caulfield wrote:

I don't know why polygate~ does show the problem where hip~ and friends don't but I'm hoping it's a clue!

So, does anyone have any (even vague) ideas of where to start before I start randomly digging?

Vague guess, might be wrong:

I think the bug is that pd -nogui loads (and possibly also loadbangs) the patches specified on the commandline before it initialises the samplerate~ and block~ settings.

polygate~ (or other broken dsp externals) are probably getting the samplerate~ or block~ settings before pd has fully initialised them. (eg: object gets samplerate in the object's 'new' method)

hip~ and friends work with various workarounds probably because they re-get the samplerate~ or block~ settings when the dsp graph is resorted. (eg: object gets samplerate in the object's 'dsp' method)

polygate~ (or other broken dsp externals) are possibly not re-getting the samplerate~ or block~ settings when the dsp graph is resorted.

This suggests a possible other workaround that combines two techniques:

loader.pd:

[loadbang] | [delay 10] delay a bit because Pd has a bug |
| [; pd dsp 1( turn on dsp to initialize things | [delay 10] |
| [; pd dsp 0( turn off dsp in case it slows down loading | [delay 10] | [; pd open main.pd .( load the main patch (syntax not tested...)

main.pd:

your normal patch, feel free to [loadbang]--[; pd dsp 1] as usual, if it doesn't work after all that fuss then I'm out of ideas.

Of course, even if the combo workaround works, it's still just a hack and pd still has a real bug that needs fixing, and the externals in question might have real bugs that need fixing too. But it'd provide a further clue.

Claude