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