Wish Better handling for "running out of CPU" situations

laxu

laxu

Fractal Fanatic
How it is now when you are close to the CPU limits of the FM3:
  • Try to add a block and the system may say "can't add block" after you have picked the block. You have to do trial and error testing if you can add it or not.
  • Try to replace a block for another one and the system says "can't add block". If you remove the block that was in that slot first, you can replace the block just fine.
  • You can add a block and instead the output is muted because it's now over the CPU limit. Why could I add the block in the first place if it makes my preset unusable?
  • CPU limit is hit at ~80% CPU usage which is confusing to the end user if you can never use that last 20%.
How it should work:
  • Blocks that will put you over the CPU limits should be grayed out from the picker so you can see immediately that the block cannot be added.
  • Replacing a block should substract the CPU usage of the existing block in that slot so you don't get that "can't add block" message.
  • You should not be able to add a block that will cause a muted output. Reducing the CPU usage by turning down e.g. Ultrares or reverb quality would simply enable more blocks in the list.
  • CPU usage should be displayed as ~80% = 100% CPU usage. Then the end user will see "I am at 95%, not going to try to add another block". Even better would be a non-numeric scale (similar to block output level bars) because the user cannot know how much CPU each block consumes without consulting the wiki so the actual percentage has little value.
 
laxu said:
  • Blocks that will put you over the CPU limits should be grayed out from the picker so you can see immediately that the block cannot be added.
  • Replacing a block should substract the CPU usage of the existing block in that slot so you don't get that "can't add block" message.
  • You should not be able to add a block that will cause a muted output. Reducing the CPU usage by turning down e.g. Ultrares or reverb quality would simply enable more blocks in the list.
Click to expand...
Fully agree. These are very good improvements. 👆

laxu said:
  • CPU usage should be displayed as ~80% = 100% CPU usage. Then the end user will see "I am at 95%, not going to try to add another block". Even better would be a non-numeric scale (similar to block output level bars) because the user cannot know how much CPU each block consumes without consulting the wiki so the actual percentage has little value.
Click to expand...
Current numeric values in percentage are useful and easy to understand, Probably many users would ask for numeric values in percentage if we have the CPU usage in a non-numeric value.... IMO current percentage values are the best option for users to manage CPU.
 
laxu said:
How it should work:
  • Blocks that will put you over the CPU limits should be grayed out from the picker so you can see immediately that the block cannot be added.
Click to expand...
I'd like to see it avoid a situation where it's teetering on the edge of being over and graying the icons then clearing them repeatedly. That'd be ugly.

laxu said:
  • Replacing a block should substract the CPU usage of the existing block in that slot so you don't get that "can't add block" message.
Click to expand...
+1
laxu said:
  • You should not be able to add a block that will cause a muted output. Reducing the CPU usage by turning down e.g. Ultrares or reverb quality would simply enable more blocks in the list.
Click to expand...
We should never be able to get ourselves into a situation like that; I think that was drummed into us in Apple's Human Interface Guidelines. Possibly the unit could remind us that reducing the quality of the IR or Reverb is an option. Getting into situations where the sound and/or responsiveness is impacted is bad.
laxu said:
  • CPU usage should be displayed as ~80% = 100% CPU usage. Then the end user will see "I am at 95%, not going to try to add another block". Even better would be a non-numeric scale (similar to block output level bars) because the user cannot know how much CPU each block consumes without consulting the wiki so the actual percentage has little value.
Click to expand...
Agreed. Subtract the necessary "rainy day fund" needed to keep the system running and make it invisible to the user. Every time I look at the CPU % I have to remember that 80-ish is pushing it, which is a bit unintuitive. Again, getting into situations where the sound and/or responsiveness is impacted is bad.
 
Greg Ferguson said:
I'd like to see it avoid a situation where it's teetering on the edge of being over and graying the icons then clearing them repeatedly. That'd be ugly.
Click to expand...
That's why you account for the worst case scenario since the CPU usage can vary a little bit. Units like the Line6 Helix or NeuralDSP Quad Cortex have zero problems doing it like this, even if that means that maybe under the hood they sacrifice an extra percentage of CPU for a better user experience.
 
laxu said:
That's why you account for the worst case scenario since the CPU usage can vary a little bit. Units like the Line6 Helix or NeuralDSP Quad Cortex have zero problems doing it like this, even if that means that maybe under the hood they sacrifice an extra percentage of CPU for a better user experience.
Click to expand...
Yes, exactly.
 
The suggested solutions don’t work because it’s not the block that increases CPU usage, it’s the channel. And CPU usage can vary A LOT per channel, up to 10%. Now multiply that with a number of blocks and you’ll see that you’ll loose a lot if you want that taken into account on forehand.

P.S. Can we avoid overusing the word “should”? EDIT: ;)
 
Last edited:
yek said:
The suggested solutions don’t work because it’s not the block that increases CPU usage, it’s the channel. And CPU usage can vary A LOT per channel, up to 10%. Now multiply that with a number of blocks and you’ll see that you’ll loose a lot if you want that taken into account on forehand.

P.S. Can we avoid overusing the word “should”?
Click to expand...
Thanks for clarifying, so more complex issue than expected. I didn't account for channels here and expected that they were taken into account already regarding CPU usage when adding blocks.

But I think you can agree that it results in many awkward situations and anything that could be done to improve this would be welcome. It's annoying to play the CPU roulette on whether the system will say "can't add", "can't replace" or just "output muted."

Obviously I'm using "should" here as just my personal opinion from the point of view of the end user.
 
Regarding CPU: TBH I'm not running into those problems. I always stay under 80% and know from experience what to expect from effect types. I realize that this doesn't apply to all users.
 
yek said:
The suggested solutions don’t work because it’s not the block that increases CPU usage, it’s the channel. And CPU usage can vary A LOT per channel, up to 10%. Now multiply that with a number of blocks and you’ll see that you’ll loose a lot if you want that taken into account on forehand.
Click to expand...
I know what you mean, but that’s not the issue here. The channels I might load or edit later have no bearing on whether I can add a block now. If adding a particular block to the grid isn’t permitted because of cpu capacity, then don’t offer it as an option in the block menu. It’s not a big problem, but it could be improved.
 
That would require the OS to know the CPU usage (on forehand) of every combination of parameters. Take the Reverb for example: Density, Quality, Diffusion etc. all have an impact on CPU usage. The OS might not let me add a Reverb at Normal quality, but what if I want to use it at Economic Quality; I would not want the OS to hide the Reverb because Normal (or High or Ultra) Quality doesn't fit.
 
Greg Ferguson said:
I'd like to see it avoid a situation where it's teetering on the edge of being over and graying the icons then clearing them repeatedly. That'd be ugly.
Click to expand...

Yeah, it would need some bit of 'debouncing' code to keep flickering to a minimum, kinda like what is done on web pages to make hover-opened menus from being flaky and jittery....
 
GlennO said:
I know what you mean, but that’s not the issue here. The channels I might load or edit later have no bearing on whether I can add a block now. If adding a particular block to the grid isn’t permitted because of cpu capacity, then don’t offer it as an option in the block menu. It’s not a big problem, but it could be improved.
Click to expand...

I feels like you are just moving the "block lottery" to the block picker. At the time of choosing you could have all the blocks on your grid set to very CPU hungry channels but you will use them in a "cheaper" state when you will need the block you are trying to add.

I personally like to have the real information coming from the machine. You have more freedom, which of course adds more possibilities to mess things up. Still, I think the advantages are much more than the issues.

It's like bending a string out of the fretboard: most of the time it's an unwanted sound but then Vai wrote The Attitude Song :)
 
yek said:
That would require the OS to know the CPU usage (on forehand) of every combination of parameters. Take the Reverb for example: Density, Quality, Diffusion etc. all have an impact on CPU usage. The OS might not let me add a Reverb at Normal quality, but what if I want to use it at Economic Quality; I would not want the OS to hide the Reverb because Normal (or High or Ultra) Quality doesn't fit.
Click to expand...
Sure, but that's not the issue here. The issue is: will the "add block" from the menu succeed? If my attempt to add the block will fail, then there's no point to offering that block as an option in the menu. Any changes I might make to the block after I add it will have no bearing on whether the add will succeed or fail.
 
How does the OS know that a block with specific settings that I saved in the Library will be loaded successfully or not, before actually loading it?
 
yek said:
How does the OS know that a block with specific settings that I saved in the Library will be loaded successfully or not, before actually loading it?
Click to expand...
No, not the block library. The right click block menu in AxeEdit when adding a block to the grid. This wouldn't make sense for the block library because you've already added the block at that point and the error message the OP referred to doesn't exist for the block library :).
 
Okay, but I rather be able to add a block, even if that gets me deep into the red temporarily, and then edit it to get CPU down, than be denied to add the block at all and have to remove another block first to make the greyed out block available again. The proposed cure just might be worse than the problem.
 
You must log in or register to reply here.
Back
Top Bottom