On Dec 17, 2007 7:33 AM, Daniel Wilcox <danomatika@gmail.com> wrote:


On Dec 17, 2007 3:06 AM, Roman Haefeli <reduzierer@yahoo.de> wrote:
On Mon, 2007-12-17 at 01:15 +0100, Daniel Wilcox wrote:
> I was under the impression that starting pd without the gui would take
> out some of the slow downs

afaik, this is only half true. please someone correct me, if i am wrong,
but i think, only the gui drawing of the windows, that are actually
displayed on screen (this includes also minimized windows), uses
additional cpu power. if your main patch shows only [pd allyourstuff]
box, then almost nothing has to be drawn.

That's basically how I have it, each major subsection is in a  subpatch:
[pd score], [pd drums],  etc so there are no dynamic objects at the root
level of the patch.


> assoicated with the gui such as gui object generation.  I have some
> objects in my rc-patches that
> build the object based on its creation args such as [rc-seq 16 4]
> makes 16 toggle boxes with 4 beat
> divisions.  Now if I have a bunch of these it slows down the loading
> of my patch considerably, which
> I understand ... but it also slows down loading in -nogui mode which I
> don't.  So is -nogui mode doing all
> of the tk work but just not drawing the window?

no. as i said before, probably not so much is used for tk. so you gain
not that much by starting pd with -nogui. i'd say most of the cpu time
on patch load is useed for generating all the dynamic objects, which
also includes recompiling of the dsp-graph, which is - again: correct
me, if this is wrong - done on every instantiation of an (~-?) object.
if this is true, the cpu time is increased exponentially  (or at least
progressively of some kind) with every new object, that needs to be
instantiated. at least that is what i experienced myself.

> The main problem is this makes patch loading realllyyy slow on my
> performance computer, PIII 500.

how slow? i mean, does it matter how slow the patch loads _before_ the
performance? does it even take more than one minute?

Yeah > 1 min, I load a new patch each time so it's unacceptable to to wait this long on stage.
I have to fix these problems before I go on tour for 3 months ... I'll mail the dates if you want to
see a pd powered explosion/crash :D


>  So I'm going to actually
> rebuild all of the songs using static objects instead of dynamic
> ones ... which is too bad because the
> flexibility of the dynamic objects was nice when creating the song
> initially.  So is that my only option
> for now, or is there some super trick I haven't noticed?

probably yes: try to switch dsp off, while all the dynamic creations are
going on and switch it on only afterwards, when everything is created.

[loadbang]
|
[t b b b]
|   |   |
|   |   'switch~ off'
|   |
|   'create all the dynamic stuff'
|
'switch~ on'

Ahh, now that makes sense I will try this and see if it helps.


i could save a lot time by doing this in netpd.

roman

Since I'm using sssad I hacked a load send to it since a loadbang, which I orginally tried, occurs *before*
the gui objects are created ... which means they don't receive their contents and the stays song is empty.



--
Dan Wilcox
danomatika
www.robotcowboy.com



--
Dan Wilcox
danomatika
www.robotcowboy.com