It means AudioMulch's overload detection was tripped. Often this happens when there is an actual overload (such as a CPU spike caused by a misbehaving plugin, or when the patch is using too much CPU) but it is also possible to have false positives.
The overload detection is new in AudioMulch 2.2 so it is possible that it's overly sensitive. Could you give some information about the system you're seeing this on? (pc/mac, asio? audio interface, buffer settings?).
If the audio is not audibly glitching then the only side effects of the red overload is that certain aspects of the clock synchronisation mechanism get reset -- so MIDI and network sync may wobble a little.
I've had this happen a number of times too. For the most part, I've tracked it down to bad plug-ins. Harmonical, for example, fries it every time you mess with the "M" settings. I've also had it happen while using too CPU-demanding patch setups, for instance while using a number of different file players at the same time running through lines of various plug-ins with complicated routing while recording the whole thing to file. I expect that's the way it's supposed to function.
My only question would be, when it does overload, it usually shreds the audio, like (in the case of Harmonical, letting out a screeching burst of harsh gritty noise and little overdriven clicks), or in the case of a more standard CPU overload, it will play the normal audio, but in pulses, like regular audio for two seconds, then no audio or a few clicks for two seconds, over and over. Thankfully, even when it does this I've found that the audio that's being recorded during the overload is not affected and that it only affects the sound output. So my question is, is that pulsing a normal byproduct? And also, even if the faulty plug-in is closed, or the more CPU-taxing processes are stopped, I've often had to close the program and restart it to resume normal function.
I'm using Windows 7, with ASIO4ALL v2, buffer set at 528. No special audio interface, just mic in and headphones out.
>>>I've had this happen a number of times too. For the most part, I've tracked it down to bad plug-ins. Harmonical, for example, fries it every time you mess with the "M" settings. I've also had it happen while using too CPU-demanding patch setups, for instance while using a number of different file players at the same time running through lines of various plug-ins with complicated routing while recording the whole thing to file. I expect that's the way it's supposed to function. <<<
Yes that all sounds normal. Especially if the displayed CPU load number is high (say 80% or above). As I said above, if there's an audible glitch in the audio then the indicator is just doing its job -- detecting the glitch.
>>>Thankfully, even when it does this I've found that the audio that's being recorded during the overload is not affected and that it only affects the sound output. So my question is, is that pulsing a normal byproduct?<<<
If the CPU overloads it means that there is not enough time to feed samples to the audio interface, and the interface is starved of audio. That will cause glitching or other kinds of buffer underrun effects (like the plusing you describe). It depends on your drivers exactly how the audio interface will behave.
>>>And also, even if the faulty plug-in is closed, or the more CPU-taxing processes are stopped, I've often had to close the program and restart it to resume normal function. <<<
That is less common. But in the case of ASIO it is really down to the driver and the hardware what happens when the CPU overloads. Next time it happens I recommend toggling audio off and on in AudioMulch (the speaker button on the tool bar). That stops and starts the driver, which often resolves this kind of issue. Let us know how you go.
I have been fooling around with a patch that includes just three contraptions yet the CPU load indicator is going red. I have a LoopPlayer playing a 123MB file and a drum machine plug in, which is a v. light load. These are connected through a mixer to SoundOut.
The CPU load indicator reading varies from only 3.0 to 6.0, but it blinks on and off in RED every couple of seconds. If I disconnect the LoopPlayer, the red stops.
Is this loop I am working with too large?
I do have my browser open and it is sucking up some CPU cycles (at most, 20%, says Activity Monitor).
The indicator showed a low value, always below ten.
Since I reported this problem, I treated my machine to some extra RAM - up from 6 to 16GB total - and now, the problem seems to have gone away, even with a bunch of other programs open and (too) many browser windows open.
For whatever it's worth, while AM says that long loop is 123MB, Mac's Finder puts it at 190MB.
Been noticing this recently too, when going from 44.1kHz patches to 96kHz ones. The CPU doubles from around 15% to 30% (which is to be expected), but the CPU load meter starts to flash red every second or so, even though there are no glitches in the audio. Latest version of Mulch, Win 7 64 bit PC, RME HDSPe AES ASIO drivers (buffer size is 512 at 44.1 and doubles automatically to 1024 when you switch to 96), 16GB RAM, i7 3.4GHz CPU, six VST plugins in the chain.
It means AudioMulch's overload detection was tripped. Often this happens when there is an actual overload (such as a CPU spike caused by a misbehaving plugin, or when the patch is using too much CPU) but it is also possible to have false positives.
The overload detection is new in AudioMulch 2.2 so it is possible that it's overly sensitive. Could you give some information about the system you're seeing this on? (pc/mac, asio? audio interface, buffer settings?).
If the audio is not audibly glitching then the only side effects of the red overload is that certain aspects of the clock synchronisation mechanism get reset -- so MIDI and network sync may wobble a little.
I've had this happen a number of times too. For the most part, I've tracked it down to bad plug-ins. Harmonical, for example, fries it every time you mess with the "M" settings. I've also had it happen while using too CPU-demanding patch setups, for instance while using a number of different file players at the same time running through lines of various plug-ins with complicated routing while recording the whole thing to file. I expect that's the way it's supposed to function.
My only question would be, when it does overload, it usually shreds the audio, like (in the case of Harmonical, letting out a screeching burst of harsh gritty noise and little overdriven clicks), or in the case of a more standard CPU overload, it will play the normal audio, but in pulses, like regular audio for two seconds, then no audio or a few clicks for two seconds, over and over. Thankfully, even when it does this I've found that the audio that's being recorded during the overload is not affected and that it only affects the sound output. So my question is, is that pulsing a normal byproduct? And also, even if the faulty plug-in is closed, or the more CPU-taxing processes are stopped, I've often had to close the program and restart it to resume normal function.
I'm using Windows 7, with ASIO4ALL v2, buffer set at 528. No special audio interface, just mic in and headphones out.
Thanks!
Vegan noise wrote:
>>>I've had this happen a number of times too. For the most part, I've tracked it down to bad plug-ins. Harmonical, for example, fries it every time you mess with the "M" settings. I've also had it happen while using too CPU-demanding patch setups, for instance while using a number of different file players at the same time running through lines of various plug-ins with complicated routing while recording the whole thing to file. I expect that's the way it's supposed to function. <<<
Yes that all sounds normal. Especially if the displayed CPU load number is high (say 80% or above). As I said above, if there's an audible glitch in the audio then the indicator is just doing its job -- detecting the glitch.
>>>Thankfully, even when it does this I've found that the audio that's being recorded during the overload is not affected and that it only affects the sound output. So my question is, is that pulsing a normal byproduct?<<<
If the CPU overloads it means that there is not enough time to feed samples to the audio interface, and the interface is starved of audio. That will cause glitching or other kinds of buffer underrun effects (like the plusing you describe). It depends on your drivers exactly how the audio interface will behave.
>>>And also, even if the faulty plug-in is closed, or the more CPU-taxing processes are stopped, I've often had to close the program and restart it to resume normal function. <<<
That is less common. But in the case of ASIO it is really down to the driver and the hardware what happens when the CPU overloads. Next time it happens I recommend toggling audio off and on in AudioMulch (the speaker button on the tool bar). That stops and starts the driver, which often resolves this kind of issue. Let us know how you go.
I have been fooling around with a patch that includes just three contraptions yet the CPU load indicator is going red. I have a LoopPlayer playing a 123MB file and a drum machine plug in, which is a v. light load. These are connected through a mixer to SoundOut.
The CPU load indicator reading varies from only 3.0 to 6.0, but it blinks on and off in RED every couple of seconds. If I disconnect the LoopPlayer, the red stops.
Is this loop I am working with too large?
I do have my browser open and it is sucking up some CPU cycles (at most, 20%, says Activity Monitor).
(AM 2.2.3RC1 on Mac)
> Is this loop I am working with too large?
There shouldn't be any problem with the size of the loop. If it loads then it should play cleanly.
When the indicator turns red does it also show a high value, or does it stay around 6 even when red?
If you're able to bundle up the AM document and the loop and post it somewhere (eg dropbox) and send me the link I can take a look here.
Thanks,
Ross.
The indicator showed a low value, always below ten.
Since I reported this problem, I treated my machine to some extra RAM - up from 6 to 16GB total - and now, the problem seems to have gone away, even with a bunch of other programs open and (too) many browser windows open.
For whatever it's worth, while AM says that long loop is 123MB, Mac's Finder puts it at 190MB.
Been noticing this recently too, when going from 44.1kHz patches to 96kHz ones. The CPU doubles from around 15% to 30% (which is to be expected), but the CPU load meter starts to flash red every second or so, even though there are no glitches in the audio. Latest version of Mulch, Win 7 64 bit PC, RME HDSPe AES ASIO drivers (buffer size is 512 at 44.1 and doubles automatically to 1024 when you switch to 96), 16GB RAM, i7 3.4GHz CPU, six VST plugins in the chain.