Thanks Joćo!<br><br><div class="gmail_quote">On Sun, Sep 26, 2010 at 6:33 PM, Joćo Pais <span dir="ltr"><<a href="mailto:jmmmpais@googlemail.com">jmmmpais@googlemail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
without knowing the patch by other than seeing it,</blockquote><div><br>Well, it's not very exportable as i have modified/overwritten some abstractions made by others. Baaad practice!<br>I'm trying to attach it now and i hope i works. Need pd-extended and many libs from it, moonlib for sure.<br>
</div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> I'll give a few pointers. the gui is the weakest link in Pd, so it's better to make it efficient<br>
<br>
- don't make the objects receive any more "state info" (data used primarily for display) than necessary.</blockquote><div><br>Sure. The step seq uses changing background colors and it seemingly makes the GUI sweat...<br>
</div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> remove repeated values with [change], or even reduce the rate with [speedlim], if a slider(knob is there for you to look at it<br>
</blockquote><div><br>These are already there, and the "alpi_c control" box sends the "control rate" number which is received by every [speedlim]<br> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<br>
- in my experience, gop with graphics showing uses more cpu than the same graphics. try to avoid unecessary gops?<br></blockquote><div><br>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! <br>
<br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
- 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.<div>
<div></div><div class="h5"><br></div></div></blockquote><div><br>Usually not, but the seq stripes have something like this...<br>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.<br>
<br>Andras<br> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div><div class="h5">
<br>
<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Dear List,<br>
<br>
I'm trying to investigate why does a larger patch slow down the GUI so much<br>
much. When opened, CPU load goes to 40-50% (when minimized, goes back to<br>
~20%), when i load values from sssad CPU goes up to 60-70% and stays there,<br>
and when i start the metro it goes even higher (not 90 or 100% however) and<br>
virtually unresponsive. Please take a look at the attached image and tell me<br>
if this is normal with a patch of this visual complexity. Make no mistake,<br>
the pd core maintains a decent 3-10% CPU load, its pd-gui which cannot<br>
handle the party.<br>
<br>
This is an ongoing problem which prevents me from actually *making music*<br>
with my patch. Tried to add the GOP abstractions to the canvas one by one,<br>
it seems that CPU load goes up by each element, i mean i couldn't find a<br>
"guilty one".<br>
<br>
Pd 42.5, Ubuntu Lucid, Compiz (<-- does it matter?)<br>
<br>
Thanks a lot for any advice!<br>
<br>
Andras<br>
</blockquote>
<br>
</div></div></blockquote></div>