Thanks Joćo!
without knowing the patch by other than seeing it,
I'll give a few pointers. the gui is the weakest link in Pd, so it's better to make it efficient
- don't make the objects receive any more "state info" (data used primarily for display) than necessary.
remove repeated values with [change], or even reduce the rate with [speedlim], if a slider(knob is there for you to look at it
- in my experience, gop with graphics showing uses more cpu than the same graphics. try to avoid unecessary gops?
- are your guis in the way of the data flow, like (process)->(gui)->(synthesis)? if no other solution, use the gui only to display the parameter's state (at a slower rate) using "set $1" messages. then when you press it, you still have control of the processes.
Dear List,
I'm trying to investigate why does a larger patch slow down the GUI so much
much. When opened, CPU load goes to 40-50% (when minimized, goes back to
~20%), when i load values from sssad CPU goes up to 60-70% and stays there,
and when i start the metro it goes even higher (not 90 or 100% however) and
virtually unresponsive. Please take a look at the attached image and tell me
if this is normal with a patch of this visual complexity. Make no mistake,
the pd core maintains a decent 3-10% CPU load, its pd-gui which cannot
handle the party.
This is an ongoing problem which prevents me from actually *making music*
with my patch. Tried to add the GOP abstractions to the canvas one by one,
it seems that CPU load goes up by each element, i mean i couldn't find a
"guilty one".
Pd 42.5, Ubuntu Lucid, Compiz (<-- does it matter?)
Thanks a lot for any advice!
Andras