Big-time CPU drainage!
I’ve made a pretty simple M4L-device, a ringmodulator with pitch-tracking, i.e., it tracks the pitch of the incoming signal and uses some userdefined fraction of that number as modulation frequency.
Everything works just fine when I have the Max editing window open, but as soon as I close Max and run it solely in Live, the CPU meter in Live starts soaring. In a matter of 20 seconds it goes from 20 to 250 percent… Needless to say, audio suffers badly…
I’m using the sigmund-external for pitch-tracking, and I’m guessing that’s the culprit.. Anyone have any bright ideas?
Hardware: Macbook Pro 15", 2,4GHz i5, 4 GB RAM, Focusrite Saffire Pro 14 soundcard
Software: OSX 10.6.7, Ableton Live 8.2.2, Max/MSP 5.1.8
All and any help much appreciated!
It seems like something is getting eaten up quickly, but without seeing a simple example, it would be hard to to tell.
Under Live Preferences->CPU, is multicore/multiprocessor support turned on? Does turning this off affect performance at all?
Hi Ben, thanks for the tip!
Multiprocessor support was turned on, turning it off made CPU-usage jump about 5 % and made it rise more rapidly once I turned on the device. Seems like there’s some kind of recursion-process going on that’s just put on halt when I turn off the device (or at least takes a long time to resolve), as the CPU-usage more or less stays at the level it was at when I turned the device back off. For instance; I open the live set, CPU-usage is at about 3-5 %. Start monitoring inputs, goes up a bit. Turn on the device in question, immediately jumps to 15% starts rising. Turn the device off again, and CPU stays at the reached percentage.
The patch is a mess at the moment, but I’m attaching it to this message, maybe someone else can make some more sense of it? You need to have the sigmund-external installed for it to work at all.
Additional info, though this’ll probably only complicate things… If I add the device to a blank Live-set, CPU usage stays at normal levels..
*rips hair out*
I loaded it, ran some audio through it and it worked fine – didn’t reach above 4% CPU. I looked inside the patch and I can’t see anything there that would cause this. I know this is no help, but if I can’t recreate it…