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.