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