[not a bug] Selecting channel that puts cpu over the limit

[GlennO]

I was running into a problem today where I would select a channel in AxeEdit on the cab block and it would kill my AxeFX. It would emit a high pitched whine and would become unresponsive. It took me a while, but I finally realized what was happening: the channel I was trying to select has 4 IR's and that would put the AxeFX over the cpu limit. The problem is there was no way to know what was killing the AxeFX. I would just press a button and the AxeFX would die. I didn't know what was on that channel, I was just trying to select an unused channel where I could put a single IR. Also, it's a difficult problem to recover from. There's no way to clear out that channel without selecting it, but you can't select it. So, I copied the current channel to the new channel, and then I was able to select it. Anyway, I thought I'd mention it in case anyone else runs into this and is stumped by what is happening.

In any case, maybe there ought to be a better way to handle this? Maybe do something similar to the case where you are prevented from adding a block that would put the AxeFX over the cpu limit?

 

[jefferski]

For the AX8, it would disable the Reverb block to keep under the CPU limit. Maybe something similar could be implemented here.

 

[yek]

For the AX8, it would disable the Reverb block to keep under the CPU limit. Maybe something similar could be implemented here.

I've always found that to be a less-than-ideal approach.

And a CPU-check when switching scenes / channels will probably increase gaps.

 

[GlennO]

I have no idea if a cpu load check would add to channel switching time, but if it did, one possibility would be to, particularly for the cab block, compute the cpu load based on the the most cpu intensive channel. That would ensure there is sufficient cpu resource when switching channels and would eliminate the need for the check. I don't like the idea of a channel I can't see contributing to the computed cpu load, but I like the AxeFX inexplicably locking up even less .

P.S. While I was trying to diagnose this, removing a reverb block didn't help, which only made things worse since it misled me into thinking the problem wasn't due to cpu load.

 

[jefferski]

I've always found that to be a less-than-ideal approach.

I agree. But better than locking up the device...

 

[yek]

compute the cpu load based on the the most cpu intensive channel.

That would get so many people in so much trouble with their current presets, and it would wreck proper preset / scenes design.

BTW, I do get the point. Keeping a preset / scene well below the critical CPU point is a good way to prevent this.

 

[GlennO]

That would get so many people in so much trouble with their current presets, and it would wreck proper preset / scenes design.

BTW, I do get the point. Keeping a preset / scene well below the critical CPU point is a good way to prevent this.

The problem is there is no clear definition for "well below". As I mentioned above, freeing up some head room for the cpu didn't work in my case.