Get rid of switching Audio GAPs p1/6 - Technical measurements and info

[BobXX]

6 oct 2023 - IMPORTANT UPDATE:
I'm crazy happy that 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​

[ Part 1 here - Measurements and Info ] current
[ 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 ]

• All my tests were done on a AXE FXIII MK2 TURBO, updated with FW v. 22.01
• I've tested all block types, in several combinations
• I've used professional instrumentation to verify what I heard with my ears,
  finding interesting information and new tricks for Fractal users
  
  
• Foreword: I am an electronics engineer who has been working in sound engineering for years; I have worked positively with Korg, Scope, Roland, and Ibanez (I mean, they do implemented some of my ideas/requirements).
  I am a rock/metal guitarist with an experience of 3 albums (few), many collaborations and +400 concerts, I think it's enough to have a possible good point of view of the requirements of a modern guitarist. I am far from being a Steve Vai though --but not a novice either.
  I love my FRACTAL AXE FXIII MKII Turbo, my inner struggle is to set it as close to my needs as possible.
  So, get out of your head that I am here to criticize, I just want to understand and find every possible solution, help/be helped. That's all.

• LATENCY: These posts aren't about latency, unless you're considering the audio gap as latency.
  Latency is the system sound delay, typical of all digital systems, caused by input A/D (Analog to Digital) conversion, fixed processing, and final output D/A conversion.
  AXE FXIII MKII TURBO has a latency of 2ms (0,002 seconds). Equivalent of staying 70cm farther from your amp.

It's known there's always a sound gap when switching presets, I've measured it between 18ms (switching to an empty preset) to ~80ms (switching to an 80% CPU preset).

See this sample test to understand the other pictures:

• blu triangle in the top is the starting point of Preset/Scene/Channel change request
• first part of the waveform is the previous sound, active for REACTION DELAY time until the system changes audio
• then there may be an AUDIO GAP: it's the stright line showing that there's no sound at all
• finally the NEW SOUND of a the new preset/scene/channel starts to be audible

I've passed from a couple of 18 yrs old rackmount BOSS GT-PRO to a new FRACTAL AXE FX3 TURBO, in this picture you can see in YELLOW the trace referring to FRACTAL AF3 and in MAGENTA the trace referring to the old BOSS GT-PRO.

We can see that reaction time is much faster in AF3 (22ms) whilst BOSS have a much slower reaction time, up to to a 65ms... but BOSS' audio gaps never go over 15ms, even switching complex Presets.
AF3 blocks (especially AMPs) are much more complex and powerful than old BOSS ones, but BOSS' CPUs are also old and much less powerful than AF3. So I admit I expected not to have gaps, at least shorter than BOSS'. That's why I needed to get rid of them somehow.

To have gapless switching sounds some suggest to stay within the same Preset, just switching scenes/channels and use modifiers.
It helps, but you may still get audio gaps.

For some type of block the scene/channel change can induce a gap. Its amount depends on more factors that we will see.

TIP for beginners:
For people used to switch presets from the foot controller, AF3's PC Mapping (SETUP-MIDI Remote) allows to associate a MIDI PC command to the same Preset and a different Scene, so it's easy to switch Scenes from an external standard Foot Controller.
The specific option "Ignore Redundant PC" eliminates the gap caused by uselessly reloading the same Preset.


"GAPLESS" BLOCKS:
In my measurements these blocks don't create gaps when switching their scenes/channels:

GAPLESS BLOCK​	REACTION DELAY (ms) @ 10%CPU (*)​	GAP (ms)​
IN	20​	0
OUT	20​	0
CROSSOVER	20​	0
DELAY	20​	0
ENHANCER	20​	0
FLANGER	20​	0
FORMANT	20​	0
GATE/EXP	20​	0
MEGA TAP DELAY (whilst MULTI TAP DELAY does cause gaps)	20​	0
MIXER	20​	0
MULTIBAND COMPRESSOR	20​	0
MPLEX	20​	0
PITCH	20​	0
PLEX DELAY	20​	0
RESONATOR	20​	0
REVERB	20​	0
RING MODULATOR	20​	0
ROTARY	20​	0
TEN-TAP DELAY	23​	0
VOCODER (it can't switch channels )	30​	0
TREMOLO	20​	0
VOLUME/PAN	20​	0
WAH	21​	0

Here's PLEX DELAY, after the reaction delay of 20ms (10 ms per division) you can see the audio continues seamlessly:




This is the case of a RING MODULATOR with different parameters set in two channels:



Again, no gaps at all !

(*) REACTION DELAYs
Typically is around 20ms. I measured it from 18ms (empty preset) up to 30ms for the more complex presets (@~ 80% CPU).
In my opinion they are OK, I'm much more concerned about the audio gaps.


"GAP TRIGGERING" BLOCKS:
ALL the other blocks do cause a GAP (I will show how to eliminate it for some of them), but their amount isn't linear and depends on more factors, two of them are:

• type of block, obvioulsy
• other concurrent channel changes

So let's see the "gap inducing" blocks with their typical minimum GAP:

GAP INDUCING BLOCK​	minimum REACTION DELAY (ms)​	minimum GAP (ms)​
CAB (legacy)	18​	12
CAB (dyna)	18​	15
CHORUS	18​	12
COMPRESSOR	18​	12
DRIVE	18​	12
DYNAMIC DISTORTION	18​	13
FILTER	18​	12
GRAPHIC EQ	18​	12
IR PLAYER	18​	12
MULTITAP DELAY (MEGA TAP DELAY is gapless)	18​	13
PARAMETRIC EQ	18​	12
PHASER	18​	12
SYNTH	18​	12
AMP	19​	~40 (Recto)
2x AMPs (switching channels of both AMPs in a preset)	19​	~65 (Recto)

It was known that AMPs are the big beasts that cause the highest audio gap.

Let's see what happens switching channels of more blocks together:

[ Part 2 here - Measurements and Info ]​

 

[Feflicker]

Saw your post on facebook the other day too. Have you read the other in-depth thread about gaps? That post outlines basically every solution.

 

[Greg Ferguson]

Can you remove the colored text please? It can be hard to read for people with varying degrees of color-blindness.

 

[RoshRoslin]

I saw this post on the facebook groups, but didn't read through the comments.

The first thing is, the thread title says "scenes and channels" but you're measuring the switching of presets, Those are three separate ways to switch sounds on any fractal products.

1) There will -always- be a gap when switching between --presets--
2) There may -sometimes- be a gap when switching between --channels--. This is block dependent. For example, Amp blocks have a gap, drive blocks do not
3) There may -sometimes- be a gap when switching between -scenes- because you may be switching channels in an amp block, for example. You can also make scene switches completely gapless if you do not have --channel-- switching done on blocks that induce a gap.

Understanding the differences between channels, scenes and presets will allow you to have gapless switching.

 

[BobXX]

I saw this post on the facebook groups, but didn't read through the comments.

The first thing is, the thread title says "scenes and channels" but you're measuring the switching of presets, Those are three separate ways to switch sounds on any fractal products.

1) There will -always- be a gap when switching between --presets--
2) There may -sometimes- be a gap when switching between --channels--. This is block dependent. For example, Amp blocks have a gap, drive blocks do not
3) There may -sometimes- be a gap when switching between -scenes- because you may be switching channels in an amp block, for example. You can also make scene switches completely gapless if you do not have --channel-- switching done on blocks that induce a gap.

Understanding the differences between channels, scenes and presets will allow you to have gapless switching.

I know, just wait my measurements, I have a lot of info I'm adding, and you will find technical confirmation of what you said, with some more info...

 

[BobXX]

Can you remove the colored text please? It can be hard to read for people with varying degrees of color-blindness.

ok

Saw your post on facebook the other day too. Have you read the other in-depth thread about gaps? That post outlines basically every solution.

As you may have read I wanted to measure and understand more in depth what happens.

 

[rossipedia]

a bit hard to read the original post in Dark Mode.

 

[Moondog Wily]

Thank you for the time and effort you are putting in to this analysis! I am sure some will find it very useful and informative!! I know I look forward to the full analysis!!! If you are interested, I did an analysis last year to measure the % of CPU for each block: https://forum.fractalaudio.com/threads/optimizing-my-fx-iii-via-cpu-block-usage.183977/ to make CPU optimization easier (and I was not the first nor will I be the last to do so I am sure). I started redoing it for FW21 and made it about half way through but got sidetracked and now intend on doing a revamp for FW22. If community members were to hop on board, we could keep such a info list updated (for all 3 current products) and I think this (like your info above) is valuable to the end users. Then again, FAS may already have this info and if they do and were able to share it with us, it would save us all some time ;~))

 

[Luke]

I’m positive Fractal knew this before this post, and are attempting to speed up without making other sacrifices. Which leaves me asking, what’s the point to troll them?

 

[BobXX]

I’m positive Fractal knew this before this post, and are attempting to speed up without making other sacrifices. Which leaves me asking, what’s the point to troll them?

Luke, you completely missed my point and I really don't understand why you are thinking bad of me.
I don't want to troll anybody, I want to have PRECISE information to manage in the best way those gaps and share information to anyone that can be interested in.
Just wait the completion of my report and then judge if there's anything offensive in it.

 

[edwinstar]

Thank you for your measurements! Very interesting read! I always had the feeling that any change of sound, regardless if there‘s a gap or not, feels like it has a gap. Now i can try to verify my assumption! Thanks!

 

[Feflicker]

ok

As you may have read I wanted to measure and understand more in depth what happens.

Unless you can debug and step through the code, you will never understand what is happening, or understand why those decisions were made. You can measure though if you find that interesting.

Cliff has said previously that they do a mute while certain things are changing to prevent audible artifacts. Id venture to guess that a solution that solves that without mutes, in the current architecture, was either not feasible or the juice wasnt worth the squeeze.

If youre a developer, reaching out to join the fractal family might be the only way youd ever really get the final answers you seek. I dont see them publically sharing more details as it is their IP.

 

[BobXX]

Unless you can debug and step through the code, you will never understand what is happening, or understand why those decisions were made. You can measure though if you find that interesting.

Cliff has said previously that they do a mute while certain things are changing to prevent audible artifacts. Id venture to guess that a solution that solves that without mutes, in the current architecture, was either not feasible or the juice wasnt worth the squeeze.

If youre a developer, reaching out to join the fractal family might be the only way youd ever really get the final answers you seek. I dont see them publically sharing more details as it is their IP.

Thank you Feflicker.
I think my list of what don't ever cause gaps, what do, and how it decreases/increases can be helpful for a lot of people to improve their experience with Fractal. This is what I wanted for me, and I'm happy to have done these tests.

When I will complete my "report" you will find that I even transformed three "gaped" blocks in "gapeless" without touching the software for most cases, and I think (IMHO) that should be very easy for Fractal to implement it as standard.
For AMPS I do have other different ideas how possibly solve their gaps, but - as you said with other words - it's easy to to have fantasies without knowledge of the code and architecture, whilst the hard developer's work is a completely different matter (in the past I was a manager of a couple of developer's team ).

 

[Patzag]

While I mostly don't particularly care about gapless switching, I find the information very interesting and well presented. If people here could let the man finish his communication without lawyering up on behalf of fractal, this might make this thread polite and interesting - yes?

 

[dean701]

I realize you are still researching and running your numbers, but I'm curious about the above measurements. Perhaps I overlooked it but what if Preset A (the starting preset) has the same amp as the destination preset? Does the refresh still take the same time? As well, do some amps have less switching times than others. I know that a few of my favs, the Atomica and the Morgan utilize less cpu than most and perhaps load quicker.

 

[BobXX]

I realize you are still researching and running your numbers, but I'm curious about the above measurements. Perhaps I overlooked it but what if Preset A (the starting preset) has the same amp as the destination preset? Does the refresh still take the same time? As well, do some amps have less switching times than others. I know that a few of my favs, the Atomica and the Morgan utilize less cpu than most and perhaps load quicker.

I tested it and it seems there aren't that type of optimisations (hope they are able to add them in the future).
The audio gap in loading a new preset depends only on its complexity (say its %CPU usage), even loading a perfectly identic preset seem not to be different from loading an completely different preset with same complexity.
The more: if you just switch the channel of an AMP with same identical type with no parameter changes you get the gap again. There may be some differences depending on "destination AMP" complexity.
I've found out that in some case staying within the same preset and changing too many channels may get a longer gap than loading an entire preset.
When I finish my work (next days) you will get a better picture.

 

[Orvillain]

There are two main ways to ensure seamless switching:

1 - Have a fixed architecture that never changes, so that on a preset load each block only instantiates its parameters, and no actual DSP nodes are unloaded and reloaded.
2 - Have enough memory and DSP processing resources to be able to load multiple presets at once, and use one of them in the background as a buffer for the current preset or the next preset, but this path introduces a lot of UX complexity.

Most other solutions are a compromise and will not offer true seamless switching. But that raises the question of whether true seamless switching is actually the goal or not.

 

[BobXX]

There are two main ways to ensure seamless switching:

1 - Have a fixed architecture that never changes, so that on a preset load each block only instantiates its parameters, and no actual DSP nodes are unloaded and reloaded.
2 - Have enough memory and DSP processing resources to be able to load multiple presets at once, and use one of them in the background as a buffer for the current preset or the next preset, but this path introduces a lot of UX complexity.

Most other solutions are a compromise and will not offer true seamless switching. But that raises the question of whether true seamless switching is actually the goal or not.

First case is not the Fractal one, and I love their full flexibility.
I think that second one is much more futuristic (it requires double resources) but in a short term I thought about something similar:
for the blocks' in the same preset, allow a specific option to preload 2, 3 or 4 channels of those blocks, to intentionally avoid the gap (accepting to consume more memory/CPU). I also have an idea about a sort of "GAP FILLER".

 

[LiamH]

@Bob4u, I'm finding this really interesting. Please continue to ignore any accusations of trolling; I think objective measurements of changes and gaps are really helpful. I can see that it might help improve the product, but from my perspective, a lot of the experience has been about realistic management of expectations. Or to put it another way, I don't change the preset I'm using during a song, ever! For effects/channel/scene changes I'm amazingly cognisant that if I have set up a potential "hold" function on the FC-12, it will have to wait and see if I'm going to release the pedal. But if I have avoided that error, your findings have illustrated and illuminated my experience.

Short answer for someone like me, that just wants to use the Axe FX III as a complete solution: It has some limitations in switching speed compared with my previous solutions of pedals and switches on a board, or hard-wired hardware solutions like TheGigRig provide. Everything I used before was essentially gapless.

Those limitations are completely outweighed by the amazing sonic capabilities of the Axe FX III, and its incredibly realistic modelling of so many different amps, speakers and effects pedals. The real answer (for me) is to understand the limitations, set up presets, effects and scenes so I can use them effectively, but most of all, to rehearse the changes so I know what to expect. Your study helps a lot with that understanding.

I bought a Russian Big Muff Pi drive pedal back in the mid-90s. Aside from the comedy size of the footswitch, it turned on when the pedal was released rather than pressed. I got over that, so I'm guessing I can get over most things!

Liam

 

[Feflicker]

Thank you Feflicker.
I think that listing what don't ever cause gaps, what do, and how it decreases/increases can be helpful for a lot of people to improve their experience with Fractal. This is what I wanted for me, and I'm happy to have done these tests.
When I will complete my "report" you will find that I even transformed three "gaped" blocks in "gapeless" without touching the software for most cases, and I think (IMHO) that should be very easy for Fractal to implement it as standard. For AMPS I do have other different ideas how possibly solve their gaps, but as you said with other words, it's easy to to have fantasies without knowledge of the code and architecture, whilst the hard developer's work is a completely different matter (in the past I was a manager of a couple of developer's team ).

I think I understand your objective. I just differ in opinion on the best way to go about it. Personally, I think posting research on social platforms, and now their own forums is not the best way to elicit a positive response. It could be seen as hostile and patronizing (the insinuation that such research would illuminate anything to the creator and team behind the product).

That said, there is a user on these forums that basically non-stop critiques every little thing, and when Fractal implements a change suggested thinks he's a genius that is driving positive change everytime he posts 1000x about the same things over and over. So we cant really say the approach doesnt sometimes yield results Hopefully your experiments will yield the changes or discussions you seek. Good luck.