[PD] -nogui question

[Daniel Wilcox]

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

>
>
> On Dec 17, 2007 3:06 AM, Roman Haefeli <reduzierer at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20071217/ee4a66b4/attachment.htm>