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