Thanks João!
On Sun, Sep 26, 2010 at 6:33 PM, João Pais jmmmpais@googlemail.com wrote:
without knowing the patch by other than seeing it,
Well, it's not very exportable as i have modified/overwritten some abstractions made by others. Baaad practice! I'm trying to attach it now and i hope i works. Need pd-extended and many libs from it, moonlib for sure.
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.
Sure. The step seq uses changing background colors and it seemingly makes the GUI sweat...
remove repeated values with [change], or even reduce the rate with [speedlim], if a slider(knob is there for you to look at it
These are already there, and the "alpi_c control" box sends the "control rate" number which is received by every [speedlim]
- in my experience, gop with graphics showing uses more cpu than the same
graphics. try to avoid unecessary gops?
Hm! Sounds interesting. "Unnecessary GOPs" are rare however, because i need to hide the guts and cables to gain space... but i'll experiment and see how it works!
- 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.
Usually not, but the seq stripes have something like this... BTW the seqs are the most primitive ones... Lots of cables, and i believe not very efficient, so if someone tells me a better way to do the same thing, i'll be happy to try.
Andras
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