Delay Block Spillover/Buffer Best Practice

NattyBar

Inspired
UPDATE: GENERAL CONSENSUS IS TO AVOID USING CHANNELS IN DELAY BLOCKS TO ADDRESS THE BELOW SCENARIOS

I've been trying to develop a solution while using delay blocks that will avoid the annoying trails/feedback being triggered when moving across scenes and channels in the delay block. It's possibly a simple setting that I've missed but after a couple of months of preset experimentation and embarrassing moments when playing live I'm in need of some guidance.

Here's an example of what I'm experiencing. If I use a delay setting (e.g. Delay 1 Channel D Reverse) at the beginning of a song, move to a different delay setting (Delay 1 Channel A Mono Tape) and then return back to the Reverse sound later on in that song the trails/spillover from when I used that delay earlier is still stored/buffered and plays immediately. In transitions or quiet parts of the song that is extremely undesirable however I'd also contend that even if the band is all in that is still unacceptable.

The issue occurs across all delay algos so it's not restricted to the above scenario. If you also change the Tempo (subdivision) you have that trail plus the speed change warble - even worse. This type of sound happens frequently as I move between scenes and delay settings quite a bit live.

I've tried different Bypass settings, different blocks for different settings, even different types of delay blocks. Still can't sort this out. Would love guidance on how to fix this issue!

I've attached the preset - I use 3rd party IRs however replaced them with representative factory options (#522 and #76).
 

Attachments

  • 220430 Marshall 1987x Morgan AC20.syx
    48.2 KB · Views: 3
Last edited:
For these things, to work properly, I prefer to use parallel routing of the delays, 100% wet with the "mute FX in" bypass setting, and if CPU allows it, I would use separate delay blocks for each delay rather than channels in a single delay block.

I am not with my Axe right now, so I cannot open your preset.
 
Ya, I know exactly what you are talking about, and I am also very interested in the solution for this. Sounds like an explosion of delay when switching back and forth between certain scenes containing different delay types.
 
use parallel routing of the delays, 100% wet with the "mute FX in" bypass setting, and if CPU allows it, I would use separate delay blocks for each delay rather than channels in a single delay block.

Parallel or series routing doesn’t make much of a difference in my experience. I do have some CPU capacity so could add delay blocks based on different subdivisions/algo if it fixes the issue. If so - it seems that the delay block is programmed in a way that changing channels freezes the delay but doesn’t clear the buffer(?)… I’ve tried hard to keep CPU usage minimal but if it’s necessary… I guess this is the work around.

the best solution currently is to use two delay blocks and switch between them with the MUX block.

Thanks for the suggestion - so putting the MUX block before the delays allows the trails of a delay to fade out when switching between outputs…. That would work except when you want delays at different points in the signal chain.

Ideally - the delay block channels would allow spillover and would clear the buffer after the trail has faded out… however no trail spillover and a hard clearing of any buffered delay signal would also be preferable to it’s current working
 
Parallel or series routing doesn’t make much of a difference in my experience. I do have some CPU capacity so could add delay blocks based on different subdivisions/algo if it fixes the issue. If so - it seems that the delay block is programmed in a way that changing channels freezes the delay but doesn’t clear the buffer(?)… I’ve tried hard to keep CPU usage minimal but if it’s necessary… I guess this is the work around.



Thanks for the suggestion - so putting the MUX block before the delays allows the trails of a delay to fade out when switching between outputs…. That would work except when you want delays at different points in the signal chain.

Ideally - the delay block channels would allow spillover and would clear the buffer after the trail has faded out… however no trail spillover and a hard clearing of any buffered delay signal would also be preferable to it’s current working
Not at my Axe to check, but if you're prefer that can't you disable spillover entirely?

That's still not a complete solution, but a better one tricky, the rub being the "after the delay trail has faded out" bit.
 
Have you tried switching between two Delay blocks when you change Scenes? It uses CPU, but can solve your problem
 
You don't need a MUX block at all. Just set your delay block's bypass mode to Mute FX In for serial delays or Mute IN for parallel delays and set the desired bypass state for each block per scene and don't change channels in any of the delay blocks.
 
Not at my Axe to check, but if you're prefer that can't you disable spillover entirely?

That's still not a complete solution, but a better one tricky, the rub being the "after the delay trail has faded out" bit.
As far as I remember, the Spillover settings are only relevant to preset changes not scene changes.

Yes the spillover setting in setup on the Axe only effects the trails when moving between presets not scene changes. The application of terminology is a little confusing in this case. Specifically, I'm referencing the trails that are retained in the delay buffer when changing channels and their 'spillover' when moving back to that channel.

You don't need a MUX block at all. Just set your delay block's bypass mode to Mute FX In for serial delays or Mute IN for parallel delays and set the desired bypass state for each block per scene and don't change channels in any of the delay blocks.

Don't change channels within delay blocks... This is seemingly the only complete solution that people have as a workaround... I guess this is easy enough to implement if there's CPU headroom. I was attempting to keep the overall CPU usage at lower levels so my main presets could be used across both the AxeFX III and the FM9 (when I'm so lucky to get my hands on one!).

a hard clearing of any buffered delay signal would also be preferable to it’s current working

I'd contend that this would be the ideal scenario when designing the use of channels for delay blocks. Clearing the buffer on channel change would in >99% of cases make the most sense in a live musical application.
 
Great description and suggestions….with you 100% on the buffer management between channels.
 
Last edited:
@NattyBar Did you find any solution for this problem? Super curious to find a fix for this as my Axe FX III is semi-unusable in live situations now because of this delay/spill/burst/glitch thing. Super weird on such an expensive product.
 
@fannar182 no fix / solution unfortunately. The patchy partial workarounds are covered above.

I’m in the habit of turning the output to zero on the actual device when there’s a low volume scene change with longer trails or higher mix settings.
 
For these things, to work properly, I prefer to use parallel routing of the delays, 100% wet with the "mute FX in" bypass setting, and if CPU allows it, I would use separate delay blocks for each delay rather than channels in a single delay block.

I am not with my Axe right now, so I cannot open your preset.
This is what I do. I have a couple of delay blocks I flip between to still allow the spills appropriately. No burst/glitches to deal with.
 
This is what I do. I have a couple of delay blocks I flip between to still allow the spills appropriately. No burst/glitches to deal with.

Yes - this is a workaround if you have the CPU headroom and blocks available... If not then there isn't a solution to the issue.
 
I do have the AF3 mkii T, so that is probably the deal maker. I have a kitchen sink preset with 2 drive blocks, 2 amp blocks, 2 cab blocks, 2 chorus blocks, 2 pitch blocks, 2 delay blocks, a comp block, a reverb block, a plex block, a wah block, a phaser block, a flanger block, a trem block, a rotary block, a filter block, and a looper block. All delays and verbs are in parallel except the plex. Most would think it is too much, but still runs 68.7% and under. I did have to make some compromises to use this type of preset on the FM9T, though.
 
Back
Top Bottom