[PD] switch~ & cputime climbing

[Derek Holzer]

This could almost be the denormal problem again. Is it an Intel 
processor on the MacBook? Intels are notorious for poor handling of 
denormal numbers, which occur when the mantissa (decimal places) of a 
number representing an audio signal becomes too long (such as happens 
with reverb tails, etc). Check the archives for more than just a bit of 
discussion on this, with some solutions (?) and certainly some workarounds.

Sounds like I need to look deeper into my own patches as well, to find 
this CPU climbing business in my granulators. I find it most weird that 
one instance has no issues, but two or more cause problems. It's like 
they interfere with each other. I rigorously checked all send/receive 
pairs and such, so I don't know what it could be at this point. Except 
grossly inconvenient!

d.

Phil Stone wrote:
> Hi Derek,
> 
> 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.

-- 
derek holzer ::: http://www.umatic.nl ::: http://blog.myspace.com/macumbista
---Oblique Strategy # 64:
"Don't stress one thing more than another"