crusher-X high CPU...

[Neon Breath]

Hello!

Out of curiosity cause I often found that crusher-X was taxing my CPU quite alot and I didn't know why since I have a powerful computer (iMac 3.4 GHz Quad-Core Intel Core i5, 8 GB RAM) I did a quick test and compared the CPU consumption against another granulator that I like and often use, SaltyGrain from SampleSumo.

I used for both plugins the exact same grain settings: total grains of 40, grain length of 1000ms, delay random variation between 0 to 500ms, Birth (IOT in SaltyGrain) of 50ms. The results were quite interesting, and radically different. With these exact same settings, crusher-X was heavily taxing my computer (Ableton Live 10.1.30) up to 50%-60%, which is monstrous imo for such conservative settings. Then with the very exact same settings in SaltyGrain, CPU consumption was around 3%-5%.

Any idea why there's such a huge different between the two? Obviously, I know crusher-X has alot more going on under the hood than SaltyGrain which is a simpler granulator but with the exact same settings and nearly the exact same granulated sound, the difference between the two is enormous.

What do you think? Curious to have your input on why such big difference...

Thanks!

[fairlyclose]

Hello!

Out of curiosity cause I often found that crusher-X was taxing my CPU quite alot and I didn't know why since I have a powerful computer (iMac 3.4 GHz Quad-Core Intel Core i5, 8 GB RAM) I did a quick test and compared the CPU consumption against another granulator that I like and often use, SaltyGrain from SampleSumo.

I used for both plugins the exact same grain settings: total grains of 40, grain length of 1000ms, delay random variation between 0 to 500ms, Birth (IOT in SaltyGrain) of 50ms. The results were quite interesting, and radically different. With these exact same settings, crusher-X was heavily taxing my computer (Ableton Live 10.1.30) up to 50%-60%, which is monstrous imo for such conservative settings. Then with the very exact same settings in SaltyGrain, CPU consumption was around 3%-5%.

Any idea why there's such a huge different between the two? Obviously, I know crusher-X has alot more going on under the hood than SaltyGrain which is a simpler granulator but with the exact same settings and nearly the exact same granulated sound, the difference between the two is enormous.

What do you think? Curious to have your input on why such big difference...

Thanks!

just did a comparison using crusherX with my old win10 i5 system using Bitwig - not exactly the same but 40 grains and lots of modulation - nowhere near that sort of CPU usage. Again in Studio One - Overall the CPU is still a fair bit, around 20%. Would be great to get it down to 5%

[Neon Breath]

Yeah, it's quite expensive here and I'm really wondering why. Did the test with few other granulators I own and none of them are near that kind of CPU consumption. The test I did is even without any sort of modulation. Just 40 grains + some randomness in the delay and grain length of 1 sec. A specific DAW issue maybe?

[freq]

I used for both plugins the exact same grain settings: total grains of 40, grain length of 1000ms, delay random variation between 0 to 500ms, Birth (IOT in SaltyGrain) of 50ms. The results were quite interesting, and radically different. With these exact same settings, crusher-X was heavily taxing my computer (Ableton Live 10.1.30) up to 50%-60%, which is monstrous imo for such conservative settings. Then with the very exact same settings in SaltyGrain, CPU consumption was around 3%-5%.

Thanks!

Hi,
Would be great if you could share your test patch so that we have a common reference. Happy to contribute with our test results.
Best
accSone

[Neon Breath]

Thanks freq for checking that out and investigating!

Sure , here's the patch test attached below. It's a very simple patch with the settings listed above in my original thread, nothing else. It easily taxes Ableton around 50%-60% with no other plugins nor tracks, just an audio track with crusher-X.

My system is: OSX 10.15.7, iMac (Retina 5K, 27-inch), 3.4 GHz Quad-Core Intel Core i5, 8 GB 2400 MHz DDR4. I use Ableton Live Suite 10.1.30 and I use a buffer latency of 1024. Also, I use the AU plugin format of crusher-X. Let me know if you need anything else or anything else you want me to try.

Link to the crusher-X patch: https://www.dropbox.com/s/b6pjp30ep2zky ... t.crx?dl=0

Thanks!

[fairlyclose]

Link to the crusher-X patch: https://www.dropbox.com/s/b6pjp30ep2zky ... t.crx?dl=0

Thanks!

I am having a play too, so I can compare my old win10 machine. With your preset as is, in Studio One, I get your result - 50%+. If I then increase Spice to max I get into the 70% range. But if I then increase Conflate to max, I get high 20%. A lot of variation according to modulation type and amount.

[freq]

Hi,
thanks for providing the test patch - to be honest, this isn't a good one for testing as it generates infinitive more and more grains and will always flood the engine with grains. The grain engine has to shut down the generation automatically by deleting grains from the que - this happens if crusher-X detects more than 70% of CPU load.

Why this happens?

If one sets longer grain lengths than the birth time (in your patch length grains 1000ms vs. birth time 50ms) these kind of scenarios lead always to an "undefined" CPU load state. crusher-X counts the birth time independent from the grain length (this might be different in other granulator plug-ins): In your example every 50ms a 1000ms grain will be launched. In the example this will be done for each generator - means 40 times. Every granular plug-in - that is "honest" - will end up in an undefined CPU state soon with these settings. Take a look at the Grain-View - you see 600 or more grains (this depents on the system power) that are processeed in parallel and are generated until the engine stops its flooding (this is by the way represented in a non colored / outlined grain representation in the Grain View - you might observed it from time to time.

Hope that helps to clarify. Let us know,
Best
accSone

[fairlyclose]

Hi,
thanks for providing the test patch - to be honest, this isn't a good one for testing as it generates infinitive more and more grains and will always flood the engine with grains. The grain engine has to shut down the generation automatically by deleting grains from the que - this happens if crusher-X detects more than 70% of CPU load.

Why this happens?

If one sets longer grain lengths than the birth time (in your patch length grains 1000ms vs. birth time 50ms) these kind of scenarios lead always to an "undefined" CPU load state. crusher-X counts the birth time independent from the grain length (this might be different in other granulator plug-ins): In your example every 50ms a 1000ms grain will be launched. In the example this will be done for each generator - means 40 times. Every granular plug-in - that is "honest" - will end up in an undefined CPU state soon with these settings. Take a look at the Grain-View - you see 600 or more grains (this depents on the system power) that are processeed in parallel and are generated until the engine stops its flooding (this is by the way represented in a non colored / outlined grain representation in the Grain View - you might observed it from time to time.

Hope that helps to clarify. Let us know,
Best
accSone

Thanks so much for this explanation
Is there a reason then to allow longer grain lengths than birth time? Maybe a warning might be useful

[freq]

Thanks so much for this explanation
Is there a reason then to allow longer grain lengths than birth time? Maybe a warning might be useful

crusher-X is designed as a "pro" instrument - our user groups are mostly serious prosumers, music and film score production studios, sound design professionals, media artists and life computer musicians - we discussed it with our customers and users several times: Shall we prevent such szenarios as described above?

We came to the following conclusion: "allow and protect" - "allow" because it is totally ok to have that grain amount growning during a limited amount of time (e.g. if you e.g. master the birth time via a MIDI controller in a life control szenario). "Protect" to prevent a state that turns down your computer (by having crusher-X self diagnosed the CPU load and protect unlimted grains to be launched - as described above).

Regarding the warning: If you're looking at the grain view you will notice that the CPU load will turn purple in such overload cases - one can takes that as a warning that your current patch launches too much grains for your system to process.

Best
accSone

[Neon Breath]

Fantastic explanation, makes sense. I get it better now. So thanks for taking the time to investigate and taking the time to explain

I'm all for the 'allow' philosophy! Actually, I was more curious than anything else on why crusher-X was eating so much resource with these actual settings. I have other tools at my disposal to counter this is if it becomes a real problem at some point, such as freezing the track in Ableton, bouncing, enabling-disabling with automation, etc. But I wanted to know what was going on under the hood a bit more.

Thanks again for your time.

[fairlyclose]

I also have no problem with this occurring - doesn't cause me any trouble at all. Just putting forward a suggestion to consider to help those for whom it might be problem. There are a couple of reasons you might want to have some sort of warning message or just flag it in the manual (maybe you already have) - mainly probably to pre-empt queries like this thread
And as an aside I am scarcely a new or casual composer - my first paid composition for theatre was I think in 1982 for a national theatre company. It used field recordings and various cutup tape techniques. Ended up being used as spot interlude - unauthorised - in sports broadcast on national TV ! Crazy.