[Implemented] Get rid of switching Audio GAPs p6/6 The "GAP FILLER..." (effective for all BLOCKS) - TIP & TRICKS

[BobXX]

[ Part 1 here - Measurements and Info ]
[ Part 2 here - Measurements and Info ]
[ Part 3 here - Measurements and Info ]
[ Part 4 here - Tips & Tricks ]
[ Part 5 here - Tips & Tricks ]
[ Part 6 here - Tips & Tricks - GAP "FILLER": GAPLESS Proof of Concept ] current

NOTE: I hereby release Fractal Audio Systems from any commitment to me concerning the contents/ideas of this post, renouncing all present and future claims in this respect.

6 oct 2023 - IMPORTANT UPDATE:
Version 23.00 public beta 1 announced:
"...Preset, Scene and Channel changes are now gapless."
https://forum.fractalaudio.com/threads/axe-fx-iii-firmware-23-00-public-beta-1.198479/#post-2467451


TIP6:
The "GAP FILLER" - Effective with all blocks

​

This post is for the cases that cannot be solved with the other solutions proposed and stimulate a discussion about two concept ideas to eliminate gaps in general.

We understood in the previous parts that some block "induces" audio gaps and others increase it.

We also understood that the obvious solution to avoid the gap is:
1) avoid to switch Presets (you'll have a gap from 18ms to 80ms depending on complexity of the preset you are going to load)
2) staying within the same preset, avoid to switch channels of "gap inducing" blocks (see lists in previous parts)

As an alternative, put two/three/four equal BLOCKs in parallel, and switch between them instead. Perfect result...
But I don't like it because I have to use 2/3/4 BLOCKs instead of switching the channels of only 1...
It's not "ecological", blocks aren't countless, CPU isn't unlimited.
In the case of AMPS I have only 2 of them and FM3 users has only 1, so they cannot do it at all.

So I wanted to find an alternative and leave the previous just for the extreme cases.

CONCEPT 1 - Preload of Preferred Blocks/channels (can someone tell if it is realistic ?):​

​

Imagining being a Fractal engineer (and I know, I am NOT, no need you to underline that I'm ignorant of inner HW/SW algorithms... blabla) I thought about a user selectable preloading of "preferred Block/channel" consuming more CPU but being more rapidly actionable reducing the gap.​

This could be a smart use of left available CPU power.​

But this is something out of my reach and not sure whether is feasible or not.​

CONCEPT 2 - The GAP FILLER ​

Theoretically feasible for Fractal even when SWITCHING PRESETs !:​

​

Imagining again being a Fractal engineer I thought about continuously store last last ~120ms in a buffer of the main outputs sound and of all active "gap inducing" blocks' output (120ms is the maximum gap I ever measured, but it could be frequently shorter),​

with a LIFO logic (Last In First Out), always running as a complete indipendent "system block".​

​

It will use very few CPU resources, and eventually could be an option that user's can activate or not.​

​

As I had demostrated:​

1) we know exactly when there will be a gap switching scenes + there's always a gap switching presets​

2) we can even estimate its amount (see previous parts)​

​

So I'm pretty sure the system knows it too, in facts it already manages a fade-out of sound and a rapid fade-in for the next sound switched (see 2nd image below).​

​

The concept is:​

​

instead of the fade-out => gap => fade-in,​

1. do a cross-fade of current sound with the bufferized sound (last XXXms of itself)
2. it will play all along the gap, filling it,
3. then cross-fade it with the new sound selected

​

The system can perfectly cross-fade those audio material because it has the timing control of everything, reducing any artifacts to the minimum. ​

In any case in 99% of cases they will be much much less audible than a total silent gap.​

PROOF OF CONCEPT
I wanted to simulate this somehow... with the limited user's powers to verify this concept.

I have found that a ducked delay could somehow distantly do it, without good cross-fadings, I know... , but I got all the same very interesting results !

Take this test chain, all "gap influencing blocks" have channel switched from Scene 1 to 2. We understood they will increase the gap even if they are inactive.

AMP (but it could be another "gap inducing block" see list in Part 1) is active to induce the gap:



This is the typical result, an audible 80ms gap:




Let's add the final DELAY Block - Digital Stereo type with the following settings:

Set time to 80-120ms (120ms it really the longest gap I ever measured in my AXE FXIII MK2 Turbo),

==> I cannot test it with FM9/FM3 so I will be happy if someone will do for me. (Soon I will receive an FM9 Turbo to check it)​

Set Mix to 100% wet and feedback R and L to 0%



In the Ducker section set Attenuation to 80dB,
Set the Threshold starting from -60/-80db to a maximum of -40db (it's a compromise point, we will see what changes)
and Release Time to its minimum, 1ms:





Check to have a full range response (some delay type have a reduced one):




Only Fractal system know in advance when sound is changing and can predict the gap, cross-fade it and so on...
what we can do with our "user's powers" is detect the total silence (unfortunately afterwards) and then start filling the gap ASAP,
then detect the new coming sound and silence the "filler".

That's what this ducked delay can do in the best case:

BEFORE:



AFTER:



The gap is nearly filled (90%, do to silence detection delay):
Gap becomes really much less audible.

In our simulation there's a problem.
I don't know why, but even if the fade-out is 10ms long (sound takes 10ms to go to zero),
changing Threshold from -30dB to -80db I can expect a difference of less than 10ms... but in reality it changes the activation of the filling from 10ms to 45ms.
I have tried all delays types with similar results:



Apparently this has no sense, but we must also understand that Ducked Delay wasn't designed for this particular use.

We only can detect the perfect silence of the gap (-80db) to activate the filling, in contrast to a real play where there's no tipically a sudden silence like that.

Setting a higher Threshold (e.g. -50dB to -30dB) you will experience a better filling but also cases when it will be activated by simply stop playing. So you will hear a tiny "bounce" in the sound, depending on your chain and playing style.
Adjust Threshold for best compromise.

NOTE: this trick must be applied before delays/reverbs in order to detect the gap silence, otherwise covered by delays/reverbs.

Anyway the concept is confirmed to be a very good compromise. It requires some improvement, if someone wishes to contribute to improve it, I will be happy to add here new details.

On the other side if FAS will implement this concept AF3/FM9/FM3 they can:

​

1) perfectly cross-fade original material and the "filling",​

cross-fading time could even be user adjustable (sudden...smooth) depending on users' needs​

​

2) the result will be 100% GAPLESS ​

​

3) the artifacts will be reduced to the minimum, rare, and much much much better than a complete silent gap​

​

4) could be possibly applied also for PRESET SWITCHING !​

​

5) very low CPU use (just short term buffers)​

​

It's not a "engineering perfect" solution but IMHO a very good hearing compromise, without doubling CPU for parallel processings.

In any case it can be an option that user can activate or not, accepting its little limitations for IMHO great benefits.


Any contribute will be appreciated.
I'm also courious about results from FM3 users.

 

[Andrew Male]

I honestly find preset switching time so quick now this has ceased to be an issue for me. If I need instant I'll use two amp blocks. CPU intensive or not, it works.

 

[md1234]

I love and was-used-to-have gapless switching, so i respect your research and sharing your ideas and measurements. Make sure to play guitar once in a while and enjoy the unit even with gaps if necessary.

 

[chris]

How much more CPU does a 2nd amp block use?

 

[unix-guy]

But I really hate this because it's a highly CPU consuming workaround,

How much more CPU does a 2nd amp block use?

This... It adds almost none since Amp modeling runs on a dedicated CPU (Axe Fx III) or dedicated core (FM9).

 

[<MACHINE>]

Wow... This is a really cool and creative way to "solve" the issue that bothers some people. Thank you for putting all the effort into working it out.

It's awesome to see how flexible this product is. Anyone can dig in and work out solutions....and get enjoyment from the process of doing such. Working out solutions to complex rig routing etc can easily be half the fun.

 

[IronSean]

My understanding is your AMP blocks don't use CPU as they're run in a separate core/CPU. All that happens is if you're using both AMP blocks they're running at ~Very High Oversampling~ instead of ~Super High Oversampling~. The waste of CPU cycles isn't so much an issue. If you need gapless switching you are probably playing live and can live with the minor decrease in oversampling resolution in the amp model. For recording you can use one amp block and not worry about the switching gap.

That said, this sort of ducking file fill is an interesting though. I could see it occasionally sounding strange in audio, but maybe less than sudden silence. On the FM3 the switching gap is still pretty noticable, so much that on my core performance patches I've started using the same amp model for all my gain tones so I don't get a gap switching from rhythm to lead tones.

 

[BobXX]

This... It adds almost none since Amp modeling runs on a dedicated CPU (Axe Fx III) or dedicated core (FM9).

Since it doesn't change the sense of the whole post, I have removed the "CPU consuming" part.

 

[unix-guy]

Since it doesn't change the sense of the whole post, I have removed the "CPU consuming" part.

Fair.

It's a cool trick and your posts are interesting.

 

[BobXX]

I love and was-used-to-have gapless switching, so i respect your research and sharing your ideas and measurements. Make sure to play guitar once in a while and enjoy the unit even with gaps if necessary.

I do, I'm enjoying Fractal, but to enjoy it better expecially in live performances I need things that it cannot provide per design.
So I have to use a lot of time to find workarounds (not only for the GAPs....) or put wishes in the wish list.
I'm sharing this information (facing some people that seem unhappy of it ) because it could be useful for you and others, and sometimes I can stimulate some contribute to improve these ideas.

 

[Orvillain]

I don't think filling in the gap with a sample is going to get you what you want. It'll just introduce more potential for dc offsets and ultimately clicks.

 

[yek]

Tried the trick but it doesn't work (as expected) because the delay kicks in any time you stop playing.

 

[BobXX]

Tried the trick but it doesn't work (as expected) because the delay kicks in any time you stop

Lower the threshold around -50 -60dB and even down to -80dB, until the kick disappears.
You can also lower the time to 50-80ms to reduce the amount of the "kick", 120ms is really the absolutely worst case.

 

[turukah]

This was a lot of fun to read. Congratulations on all the work you have done.

Since I was a kid (using a Zoom 505) I've always been annoyed by this "audio gap" that digital modelers have. More recently I started using Line 6 products (last one was the PodGo) and it was a big step forward for me with the sanpshot feature. Unfortunately, the actual sound of the Line 6 units never convinced me. I spent hours trying to dial in my tones and was never 100% satisfied, all other product features were absolutely fine... design, display, number of pedals, expression pedal, simplicity, weight, etc... but, the main thing: the sound, especially the high gain sound, was always disappointing.

I finally ended up ordering an FM3 this week and it'll be in my hands in about 2 months. So, to get the anxiety under control, I'm reading up on Fractal products and came across this, again, underwhelming Audio Gap...

Thank you very much for your work and I really hope that the Fractal engineers will pay attention to it.

PS: English is not my language... Sorry if I made mistakes in writing.

 

[km 202257]

Once this study becomes matured enough, I hope this is baked into the algorithm of the blocks that exhibit audio gaps between channel switching. Some competitors are already realizing gapless switching and this is where Fractal needs to catch up.

 

[GlennO]

Once this study becomes matured enough, I hope this is baked into the algorithm of the blocks that exhibit audio gaps between channel switching. Some competitors are already realizing gapless switching and this is where Fractal needs to catch up.

First of all, there is no catching up to be done. Competitor amp modelers offer gapless switching only at the cost sacrificing half of their cpu capacity, not because they have some magic that FAS lacks.

Second, the algorithm proposed here would not be very effective. The more common algorithm to employ in situations like this is ping pong time stretching. That would extrapolate the audio sufficiently that it would not be noticeable over a time range of a few dozen milliseconds. It's not rocket science, but it's not clear if that would be a worthwhile thing to do since the gap is not the issue. When you get the gap down to the small number of milliseconds where it is today on the Axe-FX, it's the timbre change that makes the change sound abrupt, not the gap.

The solution is to be found in cross-fading, not gap elimination.

 

[dean701]

The mission is all about the sound. Ultimately the gaps need to go. Most of us use the Fractal unit to replace the endless pedal arrays that we used to have. There were no gaps using individual pedals. There should be no gaps when using anything. Tonex, no gap, Eventide H90, no gap, gt-1000, no gap. I don't care what processor they used but the no-gap functionality is already worked out. The fractal sounds great but it still weak when it comes to gaps and midi implementation. I have no vendor bias i have no choice-supportive bias. Some people mistaking call it confirmation bias. Regardless, I am willing to try any hardware and for the most part I have. The gaps are one of the reasons I sometimes use the Tonex in the loop of my FM9. Zero gaps when switching amps.

 

[GlennO]

I think it's pretty well understood what people want. Everybody wants smooth switching, but IMHO a strategy of eliminating the amp channel switching gap doesn't address the problem.

As I mentioned, other amp modelers, notably the Helix and Headrush (I'm not sure non-amp modelers are relevant here), have the ability to sacrifice half of your cpu to achieve a smooth switch. Basically, it works by having the new preset (or channel) loaded into the processor before switching away from the old one. This technique requires paying a heavy cpu price, but in some cases it makes sense.

In other words, reducing the gap on the Axe-FX to zero wouldn't achieve what the competition has been able to do. Paradoxically, reducing the gap to zero could even make things worse because the abrupt timbre change would in many cases be worse than the fade-in/fade-out that the current gap permits. The Helix technique combats this by allowing for a brief cross-fade, but, again, at the cost of giving up half of your cpu power.

Speaking of paradoxes, it's worth mentioning that this problem is more acute with more advanced modelers. In other words, a simple modeler doesn't have this problem for the reason that the amp models to be swapped when making the change are, well, simple. A more advanced modeler, like an Axe-FX III, has a lot more to do when switching amp models, so you'll get more of an artifact, in spite of having a more advanced cpu.

One could imagine achieving a similar feature on the Axe-FX III by offering a global option like the Helix has, but realistically, giving up 50% of your cpu would make that an unattractive solution for many people. If you look at the Helix, I think it's safe to say that option is not widely used. Alternatively, an extrapolation technique like I described might work.

In the meantime, use of two amp blocks in a single preset, and cross-fading them is a darn good compromise solution for the Axe-FX III/FM9. It doesn't require you to give up half of your cpu and gives a nice smooth transition between two amp channels.

 

[State of Epicicity]

My favorite option is to load two amp blocks with the same exact four channels on each, followed by the multiplexer or mixer, switch channels on whatever amp block you're not using, then, when you're ready to switch, just hit the multiplexer or mixer to switch then. You can incorporate other types of blocks of which there are more than one instance available at a time in order to expand the idea, like having four drive blocks, two feeding amp 1 and 2 feeding amp two. Drives 1 and 2 would have identical channels, respectively, to Drives 3 and 4. Etc...

 

[BobXX]

...the gap is not the issue. When you get the gap down to the small number of milliseconds where it is today on the Axe-FX, it's the timbre change that makes the change sound abrupt, not the gap.

The solution is to be found in cross-fading, not gap elimination.

I respect your opinion, everyone has their needs and priorities.
The mine is that before cross-fading (good) I would remove those gaps somehow.

For me and other people the gap IS a problem (in live performances), forcing me to understand more about it in my AXE FX3 TURBO and taking days of time to get rid of it as much as possible.

Unfortunately it's not a small number of milliseconds. My very old BOSS GT PRO has a 15ms gap (still annoying...), in my new AX3 Turbo it may reach 80ms gap switching presets and even more switching scenes.

With this post and my Proof Of Concept in the wish list, I think I've demonstrated that this approach is effective theoretically and on the hearing point of view, it can be relatively easy to be done by FAS, without increasing significantly the CPU use.

Not only, having done it, cross-fading could be added more easily, instead of the current 10ms fade-out - silence - 10ms fade-in, we could have an user adjustable cross-fading time with the "stretched" audio, killing two birds with one stone !

I'm aware that's not a perfect solution, a perfect one means double CPU resources, but it's very very much better that a total silence for a so long time.