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
--
Friedenstr. 58
10249 Berlin (Deutschland)
Tel +49 30 42020091 | Mob +49 162 6843570
Studio +49 30 69509190
[email protected] | skype: jmmmpjmmmp
_______________________________________________
[email protected] mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
