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

[Matteo Sisti Sette]

Hi,

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.

Suppose you have a large application (for a performace, for example) with a 
lot of controllers and display that you may only occasionally need. So you 
have your main interface (i.e. most important elements you need to see all 
the time) in your main window, and lots of less critical displays and 
controllers inside subpatches or instances of abstractions. When you need to 
check out or move a display or controller, you click on the subpatch (or 
even abstraction) to show up the controllers it contains.
This is just not possible because when you do that, you suddenly get a 
second of silence (if the subpatch you open contains more than a couple of 
sliders), as audio processing holds on while drawing the gui.

Do you know of any workarounds?
Do you know if this is Windows-specific?

This is indeed another example of what I was talking about in my previous 
message under the "puredata evolution" thread.

Thanks
m. 

 
 
 --
 Email.it, the professional e-mail, gratis per te: http://www.email.it/f
 
 Sponsor:
 Prestiti Online. Scopri subito se sei finanziabile. in 24 ore senza spese né anticipi, clicca qui
* 
 Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=2908&d=4-6