[PD] switch~ & cputime climbing
martin.peach at sympatico.ca
martin.peach at sympatico.ca
Wed Jun 6 16:44:09 CEST 2007
That looks like the old denormal problem again, where the cpu goes into some kind of exception handling when a floating point value is between zero and the next smallest full-precision float, a number like 0.000000000000000001.
Martin
> I'm not positive about this, but I think I've traced the CPU-climb to
> the [moog~] filter. It has an odd behavior that can be broken into
> three phases:
>
> 1) no audio greater than zero amplitude has passed through it yet (since
> patch load)
> 2) audio of some amplitude >0 passes through
> 3) audio passing through goes back to zero amplitude
>
> At 3) (or, more accurately, several seconds after), its CPU usage climbs
> fairly dramatically, only to drop down again when the amplitude of the
> audio goes up again. Something in the filter model doesn't like zero
> amplitude, but only after it's first processed something greater than zero.
>
> I meant to test this more rigorously, but got sidetracked. At any rate,
> when I switch~ the [moog~] filter out, CPU usage holds steady. To be
> clear, I don't think this relates to [switch~]. I'm on a Macbook Pro,
> currently running 0.39rc2.
>
> Phil
>
>
>
> Derek Holzer wrote:
> > Hi Phil,
> >
> > just to keep this in people's minds... I have exact same problem
> > described in these emails with my Particle Chamber granular synthesis
> > patch. It has 32 "switch~ed" voices. Using one instance seems to be
> > OK, but two or more leads to exponentially-growing CPU usage that
> > eventually makes PD unresponsive to the GUI (and eventually would
> > probably crash PD if I let it go on...) I guess this could relate to
> > the "isn't the GUI supposed to have lower priority than process?"
> > thread, since this particular problem makes PD a bit unusable for the
> > kind of performances I want to be doing with it. The fact that PD
> > lacks a usable voice-allocation method (i.e. CPU resources can be
> > allocated and de-allocated to a voice, something which switch~ has a
> > bug with, and which Nqpoly~ and so on does not do at all) means that I
> > must start looking into SuperCollider to work with my polyphonic
> > granular synthesis stuff. Sad but true...
> >
> > d.
> >
> > Phil Stone wrote:
> >> Hi,
> >>
> >> I'm getting a slow-but-steady climbing CPU when running some
> >> synthesis patches. I (like the poster below) have sub-modules that
> >> can be switch~ed on and off. An archive search turned up the
> >> following un-replied post:
> >>> Hi all
> >>>
> >>> Okay. I'm stumped.
> >>>
> >>> Recently, I've noticed that my cpu meter has been steadily rising.
> >>> I think I may have found the culprit.
> >>>
> >>> A while back I thought I'd put a power switch (just a switch~
> >>> object) on my poor-man's granular delay line, as my performance
> >>> patches are getting a bit bulky.
> >>>
> >>> Try this (if you have the time):
> >>>
> >>> http://www.sideshowmedia.ca/cputest.zip
> >>>
> >>> cputest.pd: (needs expr, but I think that's all)
> >>>
> >>> 1. turn on audio in pd, but leave the power (p toggle) in "lois"
> >>> off. Watch the cpu meter climb (over a period of 5 minutes or so -
> >>> the toggle prints the cputime every 10 seconds). On my computer
> >>> (G4 Powerbook, HCS extended 0.38.4) it starts around 5% and hits
> >>> 10% after 5 minutes.
> >>>
> >>> 2. Do the same with "lois" on. For me, cpu hovers around 13-14%.
> >>> No increase.
> >>>
> >>> 3. Repeat step 1. After 10-15 minutes, cputime is higher than with
> >>> "lois" on. Switch "lois" on, and cpu drops. Huh?
> >>>
> >>> I have no idea what's going on, but am I missing something
> >>> important? Thanks in advance.
> >>>
> >>> cheers
> >>> dafydd
> >>>
> >>
> >> Does anybody have any insight on this? I don't remember this
> >> happening until fairly recently, but don't know if it dates to when I
> >> started switch~ing modules. I'm currently running 0.39.2-extended
> >> RC1 on a MacBook Pro.
> >>
> >>
> >> Phil Stone
> >>
> >> _______________________________________________
> >> PD-list at iem.at mailing list
> >> UNSUBSCRIBE and account-management ->
> >> http://lists.puredata.info/listinfo/pd-list
> >>
> >
>
>
> _______________________________________________
> PD-list at iem.at mailing list
> UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
>
More information about the Pd-list
mailing list