[PD] GUI speed

András Murányi muranyia at gmail.com
Sun Sep 26 22:06:10 CEST 2010


Thanks João!

On Sun, Sep 26, 2010 at 6:33 PM, João Pais <jmmmpais at 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
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20100926/d7e0e46e/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: alpi_seq_export.zip
Type: application/zip
Size: 240909 bytes
Desc: not available
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20100926/d7e0e46e/attachment-0001.zip>


More information about the Pd-list mailing list