[PD] That old -nogui/nosound problem on Linux ...

[Claude Heiland-Allen]

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