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
-
Daniel Wilcox