Closed Have the ability to set a block channel to Type = 'None' for CPU efficient scenes

Status
Not open for further replies.
This would be dangerous because you could create a preset that is under the maximum threshold and then when you change the channel you go over the threshold and get audio dropouts.
The routine should check the total load of the CPU when the channel is activated; if there is room then activate, else leave bypass on and warn the user.

Thinking about it, more than channel it should be a block bypass feature. If I wish more block in a preset but I don't use all togherer, and I am aware that "loading" the block will take a little bit of time (same as preset change)... than an option in the bypass type could be interesting. The difference with preset change is that only few block could be "unloaded"... for example if I switch between a multitap delay with controller to a hi-quality reverb, but I don't need them on at the same time, and I am at 85% CPU... I don't need two identical preset with just one different block.

Obviously there is audio dropout danger. But if the firmware check the CPU level, and stop the user to activate both block, than there is no audio problem.


The metablock should be a nightmare. I want to know where and what effect are on the grid! :)
 
Smilzo gets it. The problem of cpu spikes is a problem we are currently having to deal with as is with multiple channel changes
 
The routine should check the total load of the CPU when the channel is activated; if there is room then activate,

But if the firmware check the CPU level, and stop the user to activate both block, than there is no audio problem.

I'm often puzzled by the level of focus on monitoring and controlling cpu usage on the Axe III's Fx side cpu while there is no monitoring at all available to users for the amp side cpu (arguably the more important one), particularly for those using duel amp presets (even if only one amp is used at a time) which can run redline on the amp side cpu without any warnings popping up.
 
... there is no monitoring at all available to users for the amp side cpu (arguably the more important one), particularly for those using duel amp presets (even if only one amp is used at a time) which can run redline on the amp side cpu without any warnings popping up.
The amp side has his dedicated CPU. Cliff stated no risk of overload, I think he knows... :)
 
The amp side has his dedicated CPU. Cliff stated no risk of overload, I think he knows... :)

My experience has been to sometimes have clipping in dual amp presets with low to moderate numbers of modifiers. It's possible I am wrong since there's no Amp Side CPU status to verify my testing against, but I've checked for other reasons (i.e. output clipping / other possible issues like fan failure leading to cpu stress) and have found none with my unit which operates flawlessly within CPU limits.

Check out the attached preset (AxeIII v 12) which clips like crazy for me with 7 blocks total and a 25% visible cpu status (I'm interested to know if it clips for others). This is a more audible example - it depends on the amp models used and number of modifiers - in less audible examples you might hear a pop / crackle every minute or two when playing, but enough to be of concern particularly if recording.

I have logged a separate wish related to this (consider allowing one amp block to be allocated to the alternate CPU as a balancing option). I bring it up here as this is somewhat related to this thread. For those interested in more discussion on this amp-side cpu wish, let's take it back to the other thread I started so as not to highjack the discussion of the Fx side CPU wish stated here. (I was also attempting to explore this as a possible issue with my unit in this thread ).
 

Attachments

  • AMPSIDE-CPU-CLIPPING.syx
    48.2 KB · Views: 2
Last edited:
As an option could be interesting for AXEFX III, but really useful for FM3...

Thinking about it, more than channel it should be a block bypass feature.

Lot's of good stuff in this thread, even if it's pure fantasy. Tried to capture main ideas below (and I've added a couple along with some other thoughts):
  1. Create a null/empty/shunt/passthrough "model" for every block type (kind of like TOTALLY-FLAT IR) which is effectively a shunt model with very low CPU. This could be assigned to any channel thus giving the option to set up a minimum CPU channel. For any block, then all controls would be inactive except mix and level along with bypass options which behave as if the block was processing (but it just passes signal thru).
    Considerations: Would need to deactivate all effect-specific parameter controls or only show minimalist Mix tab. Could cause user confusion -- but any new feature can. Might effect scene/channel switching time or smoothness.

  2. A "hybrid" / "meta" / "multi-fx" / "flexi" block type that could merge different effect types into 4 channels. Benefit would be reducing block CPU footprint and simplifying grids, e.g. instead of separate phaser, flanger, chorus, rotary blocks, could combine them into one multi-fx block.
    Considerations: Might not work with current block/channel design. Would complicate UI. Could allow more than 2-4 instances of certain block types which is currently limited. Would probably only apply to FX blocks not AMP or CAB.

  3. When Mix=0, turn off effect processing / shunt signal.
    Considerations: Could cause artifacts (thumps) or audio dropouts when going back and forth from 0 to >0. Is the effect processing state pause or zeroed out when mix changed from 0? If someone wants to vary mix (e.g. with LFO or exp pedal) they might not want effect to stop running.

  4. Add a block-channel level switch: FX RUN MODE: ON (default), PAUSE (suspend processing), STOP/OFF (zero out buffers and pause)
    PAUSE would suspend/bypass the channel's fx processing and freeze its current state (if this is possible). When un-paused, the internal state/buffer would continue processing, e.g. tails resume. Could cause thumps and other artifacts but could be fine and could even be used for different effects.
    STOP/OFF would suspend/bypass the channel's fx processing and clear the channel's signal processing buffers so when turned back on there would be no output signal.
    Considerations: Could cause user confusion as another way to not understand why something seems "broken". Could cause artifacts or audio dropouts. Would allow the most flexibility with processing but also might lead to CPU overload if managed poorly. Could simply disallow a block to turn on if it causes CPU to go over 90%.

    1598337793932.png

  5. Add four new bypass modes: FX-OFF THRU, FX-PAUSE THRU, FX-OFF MUTE, FX-PAUSE THRU. Similar to 3 but also providing options for dry THRU/MUTE.
    Considerations: Similar to 3. Not as clean (data model normalized) as 3 from a design perspective.

I kind of like option 4 best for its cool "effect processing state" control (if that is even possible). Option 2 (multifx block) is also cool but less flexible than 1 or 4 and might not help with an already existing kitchen sink setup that uses many channels of different effect types. Option 1 would do the job fine with minimal change in design (except UI).

Of course Cliff already seemed to have vetoed this, but I had fun thinking about it...
 
Last edited:
I don't get why so complicated... when bypassed the block input copy to output, and (standard mode) the block process the input OR (economy mode) the block do no process it (freeing cpu & memory). So we need only a way to activate economy mode (by scene? external controller? into patch? Global?) and a way to avoid CPU hit the ceiling (locking the block in bypass state until CPU level goes down).
 
Status
Not open for further replies.
Back
Top Bottom