Axe-FX III Mark II: data loss of global settings

P

philflieger

Member
Hi,
my Axe-FX III MARK II (FW 22.1, USB 1.14 USB 1.15) forgets its global settings from time to time. Everything in the Home->SETUP menu is reset to defaults. Also the settings for the tuner is reset.
I only experienced that data loss when the device was not used for a few days.
I didn't have those problems with older firmwares < V22.0.
I use the Axe FX with an external word clock via AES/EBU (which causes that known bug of hissing noise when you turn on the device when there's no AES/EBU signal present yet).
I already checked the internal 3V CR2032 battery with a multimeter and it still provides 3V.

Has anybody had the same issues?

Edit: I just upgraded to USB 1.15.
 
Last edited:
You may have already tried this... I am assuming you tested the battery out of its holder? If so it still may be the battery. A multimeter does not put a load on the battery so it is possible for it to show 3v at no load. Hope battery swap gets you sorted.
 
Thank you for the idea.
I measured the battery "in circuit". So it should have been under it's regular load. It measured 3.069 V, independently whether the device was turned on or off. Just to make things sure I even put a 3,3 kOhm Resistor in parallel and the voltage didn't drop below 3.06V. That battery is fine.
 
It happened to me a couple of times after I sent some incorrect midi commands to it (PC 0 0, something like that) - I got a blue line accross the bottom of the screen and lots of global settings re-defaulted.
 
Last edited:
sprint said:
It happened to me a couple of times after I sent some incorrect midi commands to it
Click to expand...
That seems to be the issue! My diy midi controller polls for preset- and scene names. When the axe fx boots up it can happen that it receives only half a midi command. Then it seems to reset all it's global settings.

I think it's quite embarrassing for fractalaudio that the axe fx behaves like that. I'd expect a 'professional' piece of gear to ignore invalid midi data.

Thank you for the tip, sprint!
 
philflieger said:
That seems to be the issue! My diy midi controller polls for preset- and scene names. When the axe fx boots up it can happen that it receives only half a midi command. Then it seems to reset all it's global settings.

I think it's quite embarrassing for fractalaudio that the axe fx behaves like that. I'd expect a 'professional' piece of gear to ignore invalid midi data.

Thank you for the tip, sprint!
Click to expand...
To be fair to Fractal on this, I never reported it as a bug and probably should have reported it as an outcome of possible interest at least, tho I'm likely one of the few that's doing a lot of that type midi for my funky foot-switching system here. I'll try to isolate the scenario and report it with proper substantiating info, but I am sure that the few times it's happened, I'd found some nonsensical midi being sent to Axfx from my custom midi processes (to your point tho, ideally I'd want Axfx to reject any bad midi incoming but I don't know how common it is for devices to be parsing any bad stuff out (maybe not worth it to program for such rare occurrences) - the last time it occurred in this manner was the only time I had associated loss of global's - on previous occasions it just needed a reboot / no loss of globals - so now I'm a little more careful with my midi programming, or at least making sure I have a good backup just before delving into any significant changes to my midi processes).
 
Last edited:
philflieger said:
That seems to be the issue! My diy midi controller polls for preset- and scene names. When the axe fx boots up it can happen that it receives only half a midi command. Then it seems to reset all it's global settings.

I think it's quite embarrassing for fractalaudio that the axe fx behaves like that. I'd expect a 'professional' piece of gear to ignore invalid midi data.

Thank you for the tip, sprint!
Click to expand...
How do you know what it receives?

All the sysex that Fractal has documented includes a checksum. The intent of the checksum is to prevent invalid data is being processed.

You can try reporting this as a bug, especially if you can reproduce it...

But since it's a DIY situation, you probably want to take a really close look at your code to make sure the problem isn't originating there.

I say that because there are other 3rd party midi controllers that poll and if this issue was that simple then many people would experience it.
 
I have had the same issue several (maybe around 20) times in past years. Never, so far in current firmware. But it's seldom and not reproducible.
My suspect is also weird behavior of midi controller, it looks my pedal potentiometer - that is connected to midi controller (FAMC) - is sometimes not stable and sends random data - during booting of Axe and controller. Not confirmed, just guess.
My workaround is just label on my controller with list of AxeFx settings I need to do quickly after it would reappear :)
 
I don't know it it helps anybody, but I used a logic analyser with PulseView and recorded the midi communication for some incidents when the AxeFx III reset its global settings. You can download PulseView and load those sessions (see attached *.zip) for analysis, if you want.

In those sessions I recorded two signals:
MidiTrampel Tx: That is the data that goes from my diy midi controllers midi-out into the midi-in of the AxeFx III.
AxeFx Tx: The midi data from the midi-out of the AxeFx III into the midi-in of my midi controller.

PulseView has a decoder for UART, that you can configure to inspect the data:
UART_Decode.png

The procedure was:
  1. Start the logging session in PulseView
  2. turn on AxeFx III
  3. reset my diy midi controller
Then I waited until the AxeFx III booted completely.

Note that first spike on the "AxeFx Tx" line? That originates from flipping the power switch on the AxeFx and marks the point in time when the device starts booting.
spike.png

I don't really expect anybody to dive into that .... but who knows.

Unfortunately I can't reproduce that problem reliably. Most of the time the AxeFx boots just fine. But maybe 1 out of 20 times it resets its global settings. You can identify that it happened immediately when the AxeFx displays an apparently empty preset 000, with no names for the preset and scenes. (You have to reselect preset 000 to view the the names).
 

Attachments

  • AxeFxBugAnalyse.zip
    24.3 KB · Views: 0
Last edited:
philflieger said:
I don't know it it helps anybody, but I used a logic analyser with PulseView and recorded the midi communication for some incidents when the AxeFx III reset its global settings. You can download PulseView and load those sessions (see attached *.zip) for analysis, if you want.

In those sessions I recorded two signals:
MidiTrampel Tx: That is the data that goes from my diy midi controllers midi-out into the midi-in of the AxeFx III.
AxeFx Tx: The midi data from the midi-out of the AxeFx III into the midi-in of my midi controller.

PulseView has a decoder for UART, that you can configure to inspect the data:
View attachment 134625

The procedure was:
  1. Start the logging session in PulseView
  2. turn on AxeFx III
  3. reset my diy midi controller
Then I waited until the AxeFx III booted completely.

Note that first spike on the "AxeFx Tx" line? That originates from flipping the power switch on the AxeFx and marks the point in time when the device starts booting.
View attachment 134626

I don't really expect anybody to dive into that .... but who knows.

Unfortunately I can't reproduce that problem reliably. Most of the time the AxeFx boots just fine. But maybe 1 out of 20 times it resets its global settings. You can identify that it happened immediately when the AxeFx displays an apparently empty preset 000, with no names for the preset and scenes. (You have to reselect preset 000 to view the the names).
Click to expand...
I know this won't help most people, but since you have a custom built controller maybe you can solve it yourself:

  • Program a switch on the controller that initiates outbound communication - that way no midi is sent out until you know the Axe Fx is started and you trigger it OR
  • Program your unit to not send until it receives some specific sysex from the Fractal (you'd probably have to inspect the traffic to determine if there's a reliable message)
 
I would definitely check the data being sent from your controller when you boot it/reset/send batches of data. I encountered similar global settings/midi issues back when I used an iconnectivity device and more recently a Widi THru6 in between my midi footcontroller and the III. With the former, the unit would only select an incorrect preset and then keep the unit from responding to any other midi messages. For the later more recently, it would select an incorrect preset (usually preset 000) and wipe the global settings. In both cases, removing the intermediary midi device (both of which allowed for a second midi data source to be merged) resolved the problem immediately. So I'm guessing something is happening with the merged data that then sends a corrupted message to the III, and results in me needing to reload my global settings backups.
 
Ugh! I analyzed the data my midi controller sent to the AxeFx again and was shocked. 😲 There's in fact midi-gibberish!
In know that bug. It's a classic: wrong value for my tx buffer size that caused invalid data to be sent after valid midi data. I had eliminated that looooong time ago! But somehow must have reintroduced it. Very embarrassing.

Nevertheless this shouldn't cause the AxeFx to reset its global settings.

unix-guy said:
  • Program a switch on the controller that initiates outbound communication - that way no midi is sent out until you know the Axe Fx is started and you trigger it OR
  • Program your unit to not send until it receives some specific sysex from the Fractal (you'd probably have to inspect the traffic to determine if there's a reliable message)
Click to expand...

That's exactly what I did. Unfortunately the AxeFx usually doesn't send any "Hello, I'm awake" messages. But you can turn on "Send MIDI PC" in the "MIDI/Remote" settings. Then it sends it's currently selected preset number after boot up.

I wish Fractal had implemented that "Active Sense" midi feature. It's simple. When the midi output of a device is idle for 300 ms, it should send an "Active Sense" realtime message (0xFE). That would be perfect to determine when the AxeFx is up and running.
 
philflieger said:
Very embarrassing.
Click to expand...
Jack Nicholson Reaction GIF
 
Or as I was told once: “Just remember that when you’re pointing your finger at someone else there are another three fingers pointing right back at you”…
 
The unfortunate thing is that we still haven't found a way to reproduce that bug reliably. Without that FractalAudio has no chance to fix it.
 
You must log in or register to reply here.
Back
Top Bottom