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:
- 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.