Axe-Fx III and deconstructing / parsing a .syx / sysex preset file

ectoplasm88

ectoplasm88

Inspired
I've been reading through the forum posts, wiki, and wherever else google takes me on processing a sysex file and more specifically a Axe-Fx III preset or bank thereof. So far the only thing I think I know for sure is each line in an individual preset file will start with the header:

F0 00 01 74 10 - F0 = start of command, 00 01 74 = Fractal Audio ID, 10 = product ID of Axe-Fx II

It looks like the first line always has the command code of 77 which from other posts marks it as the header...
It looks like the last line (18th) always has the command code of 79 so I'm guessing this is just the footer/end of record marker...
All the other lines in between (16 total) are 3k in size and have the command code of 78

So obviously all the meat of the presets are in these 16 commands. After the command code 78 it seems like they all have this series of bytes:

00 08 - Not sure what to do with these?

It looks like after the 00 08 on line 2 of the presets is always followed by 13 02 00 55 54 02 then a series of 5 bytes that are specific to the patch then it seems like 00 then what appears to be the start of the patch name. Then next byte always seems to line up with the first character of the patch and I can see some subsequent characters that are part of the patch name.

So that is about as far as I've gotten so far. I'm still trying to educate myself on how to process these types of files and aside from the hex to ascii conversion I'm probably missing something on how to translate everything. If anyone has some additional knowledge they'd be willing to share it would be much appreciated. Most of what I've found only goes up to the Axe-Fx II era of products so I'm not sure how much is still true for the current presets. The author of FracTool has been able to process these files so I might be able to eventually figure it out on my own but I'd love some help.

My motivation for processing these files is to write some simple command line tools to help with preset management on my mac. Through the preset settings, tagging of scenes, etc I want to be able to quickly batch process stuff. For example I'd love to be able to quickly dump all of my presets that use a certain amp model into a folder or create a bank file from them. Maybe I come up with a scheme of tagging a scene with something like <FV> for favorite and I can quickly run a query that spits out some sort of info on those scenes are a subset. I'm also thinking I might try to build an improved preset librarian and I'd obviously like to be able to pull in all the preset info quickly. I'm dying for some better way than managing files and directories on my hard drive to organize the presets, scenes, IR's and blocks.

FracTool is awesome and I am getting started on some of this by using the export to csv feature but I'd much prefer to interact with the sysex files directly plus I'm just a geek that loves to understand things at a pretty low level.

I'll be willing to share whatever I create with the others in this community as well. Sorry if in this I'm missing some really obvious newb stuff on the sysex/midi file processing but I am a newb at it :)
 
I'm interested in preset file internals too. I wrote an IR browser for Helix, would love something like that for the III. Click the MORE INFO link to see a bit more about what it does. You can't see it actually do its thing unless you have some Helix setlist files to try it with. But it you do, you should :).

Did you ask @AlGrenadine of FracTool?

FWIW, my impression is that FracTool talks MIDI to the Axe itself, doesn't read .syx files, but I confess, I've only used it, not paid a lot of attention to how it works.
 
Last edited:
Dave Merrill said:
I'm interested in preset file internals too. I wrote an IR browser for Helix, would love something like that for the III. Click the MORE INFO link to see a bit more about what it does. You can't see it actually do its thing unless you have some Helix setlist files to try it with. But it you do, you should :).

Did you ask @AlGrenadine of FracTool?

FWIW, my impression is that FracTool talks MIDI to the Axe itself, doesn't read .syx files, but I confess, I've only used it, not paid a lot of attention to how it works.
Click to expand...
it does both
 
AlGrenadine said:
It's pretty clear : MIDI specs for 3rd party devices... so these are some basic MIDI messages
Click to expand...
So syx file specs are NOT covered in that other thread? That's what it sounds like from its title, and I'd rather skip those 11 pages if they're not about the topic I'm interested in, the topic of THIS thread.
 
Dave Merrill said:
So syx file specs are NOT covered in that other thread? That's what it sounds like from its title, and I'd rather skip those 11 pages if they're not about the topic I'm interested in, the topic of THIS thread.
Click to expand...
No they aren't. You can find few AxeFx II sysex informations on the wiki though, but no AxeFx III ones
 
AlGrenadine said:
No they aren't. You can find few AxeFx II sysex informations on the wiki though, but no AxeFx III ones
Click to expand...
Do you think Fractal is intentionally not documenting the file format for the III? It's been out for quite a while now. If so, I personally would be less inclined to build stuff on top of undocumented surmises.
 
Dave Merrill said:
Do you think Fractal is intentionally not documenting the file format for the III? It's been out for quite a while now. If so, I personally would be less inclined to build stuff on top of undocumented surmises.
Click to expand...
Absolutely ^^
TBH the file format for the II is not documented neither, had to reverse-engineer ;)
 
AlGrenadine said:
Absolutely ^^
TBH the file format for the II is not documented neither, had to reverse-engineer ;)
Click to expand...
Ugh, too bad.

In spite of what I said about not wanting to reverse engineer file specs, that's exactly what I did for the Helix IR Browser. Those files are mostly zipped json though, much more human readable.
 
Thanks everyone so far. At least this confirms what I thought about the information available. I'll continue to reverse engineer.

From the level of capabilities in FracTool it seems that @AlGrenadine figured it all out ;) . I'll keep hacking away at it on my own and as I discover stuff I'll up date this thread.

@martijne thanks for the link. I had found that document but not seen the thread on it. So far from what I've read in the thread what I concluded about it on my own was true and the information there is only helpful if I'm trying to send/receive to the unit. It doesn't delve into what is in the contents of a .syx preset file or bank. I'll read through it just for educational purposes but from the first page of chatter it does not sound like it will be too useful for my needs. Maybe they do get into the preset files later on down the line. Might be I discover that those commands listed are embedded in the preset file. Maybe there is some compression in the preset file that needs to be inflated or something along those lines making it more difficult to disassemble.

I've not reverse engineered anything in years so this will be a fun challenge. That being said if anyone wants to save me time and sanity and wants to share I'm open to that!!!! Cheers!
 
@ectoplasm88 and @AlGrenadine, it'd be great if you guys put any syx file format info you discover in the wiki.

I understand that what info you have you chiseled out with your bare hands, and that in the FracTool case it's part of a somewhat commercial product, so you may not want to just give it away, and of course that's fine.

Best of all would be if Fractal documented this stuff officially, but I understand that creating and maintaining that resource would consume scarce resources that would otherwise be advancing commercial products.

Anyway I'm all for anything that advanced the Fractal ecosystem, and information really does that. Hats off to you all however this goes.
 
So I've spent a bit more time educating myself on midi file contents and more specifically system exclusive files. Definitely revealing that system exclusive is somewhat the wild west. It has some very basic guidance to using the framework. Certainly some well known ways of using it that might be considered industry standard at times. I think its pretty obvious from the structure we see in a preset that Fractal has a well defined and rigid structure in place. I've been doing some comparison on about a half dozen preset files and I feel pretty confident the first command is always:

F0 00 01 74 10 77 7F 00 00 00 01 1C F7 - Guessing this whole line is the preset id so all the tools know they are dealing with a preset. I'm guessing that is what the "77" byte is then 1C is probably a checksum although I haven't calculated it.

Next observance... in all 6 files the second command starts with:
Hex - F0 00 01 74 10 78 00 08 13 02 00 55 54 02
ASCII - ð..t.x.....UT.

I'm pretty confident that this is the marker for the preset name. In all the files I looked at there are 6 bytes following that which are unique then the seventh is always the first letter of the Preset then a fixed length of bytes before hitting a block of white space. I'm guessing that is some additional space for longer preset names or notes or something of that nature to future proof the format a bit allowing for some expansion without needing to modify the structure of the preset files. Here is a comparison of a couple of files moving forward from the header I listed above:

Preset Name: Test2 Patch 113FILLEDTO THE END
Hex - 26 10 03 0F 18 00 54 4A 01 73 68 01 32 40 00 50 42 01 74 46 01 68 40 00 31 62 00 33 0C 01 49 18 01 4C 0A 01 44 28 01 4F 40 00 54 10 01 45 40 00 45 1C 01 44
ASCII - &.....TJ.sh.2@.PB.tF.h@.1b.3..I..L..D(.O@.T..E@.E..D

Preset Name: Spy Guitar
Hex - 07 73 00 0F 18 00 53 60 01 79 40 00 47 6A 01 69 68 01 61 64 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ASCII - .s....S`.y@.Gj.ih.ad................................

After that there is a consistent amount of white space:
004Fh: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
005Fh: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
006Fh: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
007Fh: 00 00 ..

As you can see above some of the preset name is definitely readable. I just need to figure out the correct way to process the information. Its a little lower level than I am ever needing to deal with information but from what i've read it looks like I just need to do the correct conversion and the full name will emerge. Looking over the midi file spec and I see a bunch about everything being stored as 7bit bytes so maybe that is why some stuff is readable while other stuff isn't. I'd also long forgotten about the term "endianness" but it might come into play here related to the byte/bit order of things.

One other pattern I am seeing even within a single command is the F0 00 01 74 10 78 00 08 series of bytes. I am seeing this within the command block so obviously multiple commands are within this 3k command block. Maybe 3K is the max size per sysex command and if you are streaming a big dump this is a common way to embed more than a single command?
 
Adding to my observations earlier today it seems like every other character in the stream around the name is two bytes. If I use "Spy Guitar" as an example:

Hex is - 53 60 01 79 40 00 47 6A 01 69 68 01 61 64 01
Ascii is - S`y@Gjihad

S = 53
p = 60 01
y = 79
space = 40 00
G = 47
u = 6A 01
i = 69
t = 68 01
a = 61
r = 64 01

I'm sure I'm missing something painfully obvious with the encoding of this. Any other coders on here wanna help? I'm wondering if its some sort of alignment thing? Seems like all of these characters should fit into a single byte so not sure why two bytes on every other. I'm thinking its something in the binary translation that I'm not understanding.
 
ectoplasm88 said:
Adding to my observations earlier today it seems like every other character in the stream around the name is two bytes. If I use "Spy Guitar" as an example:

Hex is - 53 60 01 79 40 00 47 6A 01 69 68 01 61 64 01
Ascii is - S`y@Gjihad

S = 53
p = 60 01
y = 79
space = 40 00
G = 47
u = 6A 01
i = 69
t = 68 01
a = 61
r = 64 01

I'm sure I'm missing something painfully obvious with the encoding of this. Any other coders on here wanna help? I'm wondering if its some sort of alignment thing? Seems like all of these characters should fit into a single byte so not sure why two bytes on every other. I'm thinking its something in the binary translation that I'm not understanding.
Click to expand...
See the wiki
Midi is 7bits data, apart control bytes
 
I went ahead and put together a little program to start parsing these files. I see now with the patch name in some cases bits are being shifted so I can calculate the correct ascii characters. Like from the example above where I get the tick + 01.
The binary value for "p" is 1110000 and when I am seeing the 00 or 01 following the previous hex value I know it was shifted and I can shift it back.
p = 1110000
` = 1100000

For some reason I'm not quite getting why some are being shifted and others aren't. I now understand that in the midi messages the 8th bit is basically reserved to mark a midi control so F0, 77, 78 etc are all some sort of control which only leaves the 7bits for data as the first bit always needs to be a 0. It seems like something else is going on within those 7 bits though that I'm not getting. Seems like it should be a byte per character unless the character value was beyond 127?
 
You've likely already hit these resources up, but I'm putting this in this thread for others since this thread will show up in searches later.

You need to start with this page: https://wiki.fractalaudio.com/wiki/index.php?title=MIDI_SysEx
That page describes all of the SysEx functions.

Then the parameter ID page: http://wiki.fractalaudio.com/axefx2/index.php?title=MIDI_SysEx_blocks_and_parameters_IDs

Other References:
Git Repo of main features on using Arduino Library
https://github.com/tysonlt/AxeFxControl

More about block parameters:
https://wiki.fractalaudio.com/gen1/index.php?title=Axe-Fx_SysEx_Documentation#Amp_Block_Parameters

Old, but useful info that may provide different representation of the same information in the WIKI:
http://www.gmarts.org/html/axefx_ultra_sysex_1005.html
 
You must log in or register to reply here.
Back
Top Bottom