[PD] isn't the GUI supposed to have lower priority than process?

[Jamie Bullock]

Hi Matteo,

On Mon, 2007-06-04 at 22:04 +0200, Matteo Sisti Sette wrote:
> I always thought that in PD, "process" (i.e. dsp and control processing) had 
> the priority over GUI rendering, in such a way that drawing the gui would 
> NEVER cause audio clicks although this means there's no warranty about how 
> much gui rendering may be delayed.
> 
> To my great disappointment, I see that when opening a subpatch with a lot of 
> gui, audio clicks are produced. Just opening it, i.e., right-clicking on it 
> and "open" (or just left-clicking when not in edit mode)
> Not to mention moving around a "big" GOP-enabled object (or, I guess, a 
> handful of gui elements at the same time).
> But the first one seems to me a much more severe problem.
>
> Do you know of any workarounds?
> Do you know if this is Windows-specific?
> 

I haven't experienced this problem myself because I hardly use any GUI
stuff in performance. However, one way to avoid it might be to run two
instances of PD, one for the GUI, and one in -nogui mode, and use some
network protocol (OSC, FUDI), to send data between them. That way you
have your GUI and audio processing running as seperate processes in the
OS. At least on *n*x you can then optionally assign a priority to each
process using something like 'nice'.

Jamie