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
_______________________________________________
[email protected] mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
