Axe-Fx III Firmware 24.02 Beta #1

[sprint]

Yep. Build something like this, which runs two lines in parallel, a "dry" line and another line that passes through the loop, and you can test it yourself.

Set the Return block to Mute Out and flip it on and off. Aside from the change in volume from doubling the signal, you'll hear a change in phase, which tells you the timing between the two routes are different. This is due to the Send Return loop adding latency.

And he's correct. The blocks don't add latency. The way the Axe-Fx processes signal, combined with how the blocks function, is what adds latency.

If you build this:

...then there is no added latency.

So what's happening? Why does placing the Send block to the right of the Return block add latency to the overall signal? And why is there no added latency when the Send block is placed to the left of the Return block? Well, each cycle of Axe-Fx processing is done left-to-right on the grid. One pass is done and the signal hits the Send block. That signal does not actually come out of the Return block until the next left-to-right frame pass. This necessarily adds latency.

No extra latency is added when the Send block is placed to the left of the Return block on the grid because the signal that hits the Send block can be immediately transferred to the Return block all in the same processing frame.

I'm not just making it up. You can do this experiment in your Axe-Fx right now to confirm it.

Astute observations - I'm goona try n measure how long that is

 

[Dave Merrill]

And he's correct. The blocks don't add latency. The way the Axe-Fx processes signal, combined with how the blocks function, is what adds latency.

If you build this:

...then there is no added latency.

So what's happening? Why does placing the Send block to the right of the Return block add latency to the overall signal? And why is there no added latency when the Send block is placed to the left of the Return block? Well, each cycle of Axe-Fx processing is done left-to-right on the grid. One pass is done and the signal hits the Send block. That signal does not actually come out of the Return block until the next left-to-right frame pass. This necessarily adds latency.

No extra latency is added when the Send block is placed to the left of the Return block on the grid because the signal that hits the Send block can be immediately transferred to the Return block all in the same processing frame.

I'm not just making it up. You can do this experiment in your Axe-Fx right now to confirm it.

Well dang, didn't know that.
Worth keeping in mind, since I use send/return pairs in many of my presets, just so stuff fits.
Pretty much think this should be discussed in the official documentation.

 

[TheRedDevil]

Well, I switched back to 23.05. after testing some Gary Moore presets from AXEchange. I got some hanging red input lights but AXE FX did not crash totally.

 

[Jason]

I heard pops when changing scenes using firmware 24.01. I installed 24.02 beta 1 and gigged it last night. No pops. Yes!

 

[TheRedDevil]

Well, I switched back to 23.05. after testing some Gary Moore presets from AXEchange. I got some hanging red input lights but AXE FX did not crash

Just changed cmp to looper and changed preset but with 23.05 the error occurs too. Double Verb preset

 

[FractalAudio]

Well, I switched back to 23.05. after testing some Gary Moore presets from AXEchange. I got some hanging red input lights but AXE FX did not crash totally.

Presets work fine here.

 

[FractalAudio]

Just changed cmp to looper and changed preset but with 23.05 the error occurs too. Double Verb preset

This thread is about firmware 24.02. Regardless, I cannot reproduce that error.

 

[TheRedDevil]

This thread is about firmware 24.02. Regardless, I cannot reproduce that error.

I will reinstall 24.02b1 tomorrow and try it again. If error still exist, I make a backup, reset of AXE FX, test it and recover my settings and test it again. Merry Christmas.

 

[TheRedDevil]

This thread is about firmware 24.02. Regardless, I cannot reproduce that error.

It depends how load Output Volume 1 is set. I hear a short "clink" sound when I replace the wah with the looper and just if output vol pot is on full, its led shows red all the time. If it is not on full, it is only on red shortly together with that sound. I also had this sound, when I pressed Begin (Update) in Fractal Bot. I installed 24.02b1 again. Same result.

 

[FractalAudio]

It depends how load Output Volume 1 is set. I hear a short "clink" sound when I replace the wah with the looper and just if output vol pot is on full, its led shows red all the time. If it is not on full, it is only on red shortly together with that sound. I also had this sound, when I pressed Begin (Update) in Fractal Bot. I installed 24.02b1 again. Same result.

https://forum.fractalaudio.com/thre...the-axe-fx-iii-fm9-or-fm3.191369/post-2490036

 

[Moondog Wily]

https://forum.fractalaudio.com/thre...the-axe-fx-iii-fm9-or-fm3.191369/post-2490036

Maybe ^^^^^^^^
needs to be in your signature
v v v v v v v v v v!

 

[swass]

A Very Mery Christmas and Happy New Year to Cliff, FAS, forum partiscipants and lurkers.

 

[Dave Merrill]

And he's correct. The blocks don't add latency. The way the Axe-Fx processes signal, combined with how the blocks function, is what adds latency.

If you build this:

...then there is no added latency.

So what's happening? Why does placing the Send block to the right of the Return block add latency to the overall signal? And why is there no added latency when the Send block is placed to the left of the Return block? Well, each cycle of Axe-Fx processing is done left-to-right on the grid. One pass is done and the signal hits the Send block. That signal does not actually come out of the Return block until the next left-to-right frame pass. This necessarily adds latency.

No extra latency is added when the Send block is placed to the left of the Return block on the grid because the signal that hits the Send block can be immediately transferred to the Return block all in the same processing frame.

I'm not just making it up. You can do this experiment in your Axe-Fx right now to confirm it.

Can we get official confirmation of this concept please, or a statement that it's mistaken?

EDIT: Just to be clear, I very much appreciate your detective work and analysis @GreatGreen. It's not so much that I doubt your investigation, it's that this is an important principle for us preset builders to be aware of, one I've never seen mentioned before. Nailing it down officially for real would be good.

 

[TheRedDevil]

I know, just a stupid customer ... You know I test here for free, I also could use my time for other thinks. I thought my example is clear enough. Sorry guys, no beta test anymore for next year.

 

[TremoloFan]

I know, just a stupid customer ... You know I test here for free, I also could use my time for other thinks. I thought my example is clear enough. Sorry guys, no beta test anymore for next year.

You also get new features, fixes and updates for free. Fair trade for sure! I have no doubt if you would submit bugs as requested, you’d get a satisfactory response. Merry Christmas to those who celebrate!

 

[Moondog Wily]

Not sure why we need to get so reactionary! Cliff has had to remind several users of the way to post bug reports over the past couple of weeks. I think it would be easiest for him to just use a v v v v in his responses when noting that users should deliver their bug reports under the format necessary to provide solutions in the most efficient manner. If somebody wants to run and hide in the corner based on such a request, so be it, I don't manage others triggers!!!

 

[TheRedDevil]

I posted a video based on a standard preset. More is not possible without availability of logfiles or trace logs.

 

[notalemming]

I posted a video based on a standard preset. More is not possible without availability of logfiles or trace logs.

Really?!?!?! None of this is possible:

When reporting bugs:
1. Post an example preset.
2. Do NOT post a preset bundle.
3. Simplify the preset as much as possible. Remove any blocks that are not relevant.
4. Unlink all blocks from global blocks.
5. Use factory cabs if possible.
6. Include clear and concise instructions on how to recreate the bug.


In the time you took to post something that is not what Cliff needs & complaining about him having the audacity to post what he asks of everyone posting a bug report, you could have done what he asked & likely might even have a solution by now. You're just shooting yourself in the foot!

 

[TheRedDevil]

When reporting bugs:
1. Post an example preset.

Everybody has that preset, factory preset Double Verb

2. Do NOT post a preset bundle.

I did not do that

3. Simplify the preset as much as possible. Remove any blocks that are not relevant.

I don't know what is relevant and what is not for Cliff. Be more precise.

4. Unlink all blocks from global blocks.

What is a global block (definition)? GEQ?

5. Use factory cabs if possible.

Standard preset = factory

6. Include clear and concise instructions on how to recreate the bug

A video is clearer than any description

If FAS wants more they should implement a savelog feature to get all they need. This just frustrates customers to support. I know what I'm talking about from work.

 

[Randalljax]

I posted a video based on a standard preset. More is not possible without availability of logfiles or trace logs.

Everybody has that preset, factory preset Double Verb

I did not do that

I don't know what is relevant and what is not for Cliff. Be more precise.

What is a global block (definition)? GEQ?

Standard preset = factory

A video is clearer than any description

He wants your preset regardless if it factory , there could be an issue in that preset somewhere on your unit