Reverse engineer undocumented sysex?

P

philflieger

Member
Has anybody reverse engineered the sysex format of those messages that aren't documented in Axe-Fx III MIDI for Third-Party Devices? Like commands 0x51, 0x52, 0x53?

Background: The Axe-Fx III has a bug. It occasionally resets all global parameters to default values when you spam it with midi data during boot up.
Thus I'd like to send configuration data with my diy midi controller so that I can set parameters like:
  • External Control CC
  • Tuner Config
  • Global Settings
etc

All that data is stored in a *.syx file when you make a back up of your system data with Fractal-Bot. But before I start reverse-engineering the sysex data myself, I wanted to ask if anyone has already tried this.
 
philflieger said:
Background: The Axe-Fx III has a bug. It occasionally resets all global parameters to default values when you spam it with midi data during boot up.
Click to expand...
I’d concentrate on finding a repeatable example of the problem and post that. Once we can replicate it Fractal can fix it.

philflieger said:
Thus I'd like to send configuration data with my diy midi controller so that I can set parameters like:
  • External Control CC
  • Tuner Config
  • Global Settings
Click to expand...

Some parameters may not be exposed in a way that can be externally accessed by MIDI and .syx files can be anything that the vendor wants them to be and their interpretation is up to the internal code in the modeler. It might be easier to write a wish post and justify why those should be exposed and documented.
 
AlGrenadine said:
The syx files won't help you much, you'll have to sniff the midi traffic
Click to expand...
Probably I'm too naive and don't understand why yet.

When I dump the system settings with Fractal-Bot I get a *.syx file. It contains plain sysex data. I can use any tool (e.g. midiox) to send that sysex data to the midi input of the AxeFx III. That restores those system settings. I tried that successfully.
Thus I don't understand why I have to spy the midi traffic for that purpose.
The only problem is that the entire *.syx file is waaay to big for the flash memory of my diy midi controller. So I hope that I can generate smaller sysex data that contains only those of my settings that are different from the factory defaults. But for that I have to understand that format.

What I see is:
  1. The backup consists of many sysex messages
  2. Each sysex message starts with the manufactorer id, probably followed by a command id
  3. The first sysex has the command id is 0x51
  4. It is followed by 64 sysex messages with command id 0x52
  5. The last sysex has the command id 0x53
Here I stopped analyzing because I hoped that someone else has done that already. Maybe even with the conclusion that it is futile because of ... reasons. Reasons that I can't see with my limited knowledge yet.
 
philflieger said:
Probably I'm too naive and don't understand why yet.

When I dump the system settings with Fractal-Bot I get a *.syx file. It contains plain sysex data. I can use any tool (e.g. midiox) to send that sysex data to the midi input of the AxeFx III. That restores those system settings. I tried that successfully.
Thus I don't understand why I have to spy the midi traffic for that purpose.
The only problem is that the entire *.syx file is waaay to big for the flash memory of my diy midi controller. So I hope that I can generate smaller sysex data that contains only those of my settings that are different from the factory defaults. But for that I have to understand that format.

What I see is:
  1. The backup consists of many sysex messages
  2. Each sysex message starts with the manufactorer id, probably followed by a command id
  3. The first sysex has the command id is 0x51
  4. It is followed by 64 sysex messages with command id 0x52
  5. The last sysex has the command id 0x53
Here I stopped analyzing because I hoped that someone else has done that already. Maybe even with the conclusion that it is futile because of ... reasons. Reasons that I can't see with my limited knowledge yet.
Click to expand...
You will then only be able to download / upload the whole system bank.
It's not clear what you're trying to achieve though
 
AlGrenadine said:
You will then only be able to download / upload the whole system bank.
It's not clear what you're trying to achieve though
Click to expand...
I'd like to upload only those sections of the system bank that contain the settings I want to alter, e.g. the configuration of the tuner.

If there are other means to set those settings by midi - even better! But I don't know any.
 
philflieger said:
I'd like to upload only those sections of the system bank that contain the settings I want to alter, e.g. the configuration of the tuner.

If there are other means to set those settings by midi - even better! But I don't know any.
Click to expand...
Then what you want is only setting a parameter to a value. That's why you'll need to sniff...
 
Greg Ferguson said:
I’d concentrate on finding a repeatable example of the problem and post that. Once we can replicate it Fractal can fix it.
Click to expand...
I'd really like to, but I haven't found a way yet. I only observed that occasionally my global settings got wiped when I simultaneously turned on the AxeFX III and my diy midi controller . My controller didn't wait for the AxeFX and immediately started polling for preset/scene names.

Meanwhile I already altered my diy midi controller so that it waits for the AxeFX to boot. (signalled either by midi data sent from the AxeFX or by the user pressing a physical button).
 
AlGrenadine said:
Then what you want is only setting a parameter to a value. That's why you'll need to sniff...
Click to expand...
Do I have to analyze a request-response ping-pong in the communication? I doubt that because when I use midiox to send the sysex data it works just fine. Shouldn't comparing differences of *.syx files with different settings do the trick just fine?
If for (unknown?) reasons it is not possible to send only a part of the system bank then sniffing doesn't help either.
 
philflieger said:
Do I have to analyze a request-response ping-pong in the communication? I doubt that because when I use midiox to send the sysex data it works just fine. Shouldn't comparing differences of *.syx files with different settings do the trick just fine?
If for (unknown?) reasons it is not possible to send only a part of the system bank then sniffing doesn't help either.
Click to expand...
Yes, you have to sniff what Axe3Edit does when modifying a parameter (a setup parameter in your case)...
Sending "a part of" a bank/preset/ir/anything doesn't exist
 
philflieger said:
Yes. And they tried, but they can't reproduce it.

See
https://forum.fractalaudio.com/threads/bug-losing-global-settings-during-boot.199876/
https://forum.fractalaudio.com/threads/axe-fx-iii-mark-ii-data-loss-of-global-settings.197303/
Click to expand...
The first guy fixed his issue by replacing the battery.

The second one.... you say you tested the battery and it checks out fine.

Then you say this:
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...

Have you confirmed that bug is not with your DIY midi controller? If so, how did you confirm it?
 
philflieger said:
When I dump the system settings with Fractal-Bot I get a *.syx file. It contains plain sysex data. I can use any tool (e.g. midiox) to send that sysex data to the midi input of the AxeFx III. That restores those system settings. I tried that successfully.
Click to expand...
Just curious, as I thought a system settings restore required a system reboot -- did it require a reboot or did the system settings immediately take effect?
 
Orvillain said:
Have you confirmed that bug is not with your DIY midi controller? If so, how did you confirm it?
Click to expand...
My midi controller isn't perfect by any means and I very well consider the possibility that it might be the culprit.

But I used an oscilloscope to verify that it produces electrical signals that are within midi specs. No over- or undervoltages, timing ok. Additionally I used a logic analyzer to record and verify that the midi data it produced, was as I intended. I managed to record incidents when my midi controller made the AxeFX reset its data. I didn't spot any difference in the midi data I fed it with.

I am very well aware that I flooded the AxeFX with midi data whether it was ready to receive or not. Thus I consider the hypothesis plausible, that the cause could be a matter of timing and crippled data. Plausible, but not proven! Other hypothesis are welcome!
 
sean.e said:
Just curious, as I thought a system settings restore required a system reboot -- did it require a reboot or did the system settings immediately take effect?
Click to expand...
I did this test:
  1. On the AxeFx enter the "Midi/Remote" screen, "External" page.
  2. Set "External Control 1" to a value like "CC #16"
  3. Use Fractal-Bot or midiox to send a system backup *.syx file to the AxeFX
  4. Observe the "External" page on the device
When the transfer of the backup has completed it displays the "External Control 1" value as it was stored in the backup file.
I wouldn't claim that all system settings take effect without reboot. But the value for "External Control 1" is displayed without reboot.
 
Orvillain said:
The first guy fixed his issue by replacing the battery.

The second one.... you say you tested the battery and it checks out fine.

Then you say this:


Have you confirmed that bug is not with your DIY midi controller? If so, how did you confirm it?
Click to expand...
There have been others that have reported the same problem over the years, with a common factor of using an external midi controller that was sending midi to the Fractal during boot.

A bad battery doesn't require that part... The settings will disappear when the battery power is insufficient.

It is a possibility that is something specific from the custom controller but it is probably not a coincidence that it has happened with other controllers.
 
You must log in or register to reply here.
Back
Top Bottom