On Dec 17, 2007 7:33 AM, Daniel Wilcox <[EMAIL PROTECTED]> wrote: > > > On Dec 17, 2007 3:06 AM, Roman Haefeli <[EMAIL PROTECTED]> 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
_______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
