Differences between the Axefx Ultra and Axefx2 midi formats?

fret

fret

Experienced
Is there a good run down of the differences between the 2 units?

At the moment I support the Ultra (because I have one) and I've heard some things are different on the Axefx2 midi wise. And I'd like to update my controller firmware to talk to either unit before I actually get a chance to connect to an Axefx2.
 
Did you mean in the structure of the SYSEX strings?

If so, The biggest change is that there is now a checksum byte in the sysex strings sent to the Axe-FX. I just made some additions to the Axe-FX2 Wiki last night to try and document this.

The other major change is that when you send values to the Axe-FX, they are now contained in a 3 byte block which is structured differently from the old 2 byte (hi/lo) segment on the Ultra. If I get some time in the next day or so, I will try and document that on the Wiki too...
 
  • Like
Reactions: jon
Great. So in general do controllers "detect" which version of the Axefx they are plugged into or is it a configuration setting?
 
Either way. You can 'detect' the version of the Axe-FX by sending a specific SYSEX string to the device and checking the response. Or else you can go option 2 to let your users select the device type on your controller manually, and then change the SYSEX sent to the device based on that.

If you send the SYSEX string:

F0 00 01 74 00 08 00 00 F7

The device will respond with the following SYSEX string (Below example is the response from an Axe-FX Ultra with Firmware 10.03):

F0 00 01 74 01 08 0A 03 F7

The fifth byte (01 in this case) denotes the device type. 00=Standard, 01=Ultra, 03=Axe II

The seventh and eight bytes denote the firmware version on the device. Seventh byte (0A) is the major version number, and Eight (03) is the minor version, so the above response would denote Firmware 10.03.
 
  • Like
Reactions: jon
jon said:
^ I think I should wiki that.....
Click to expand...

Sure thing! I was going to try and put it on the Wiki myself when I got a moment. I think the basics of this function is on the old Wiki under the 'Ultra MIDI SYSEX' page. I just paraphrased that content a little bit on here. It could probably be written in a more 'layman's fashion' on the new Wiki though.

I plan to post all the knowledge I have learned during the development of AxePad on the new Wiki... not only to help others, but because my memory these days is so damned terrible that I have forgotten code I wrote just last week! :D
 
  • Like
Reactions: jon
I didn't know AxeFx sysex was documented !
So i assume it is now possible to create a tool converting an Ultra .syx file to a II .syx ??
 
My recollection is that at least in earlier firmware versions, the II would not respond to ill-formed firmware version requests. It wanted the checksum: F0 00 01 74 03 08 0A 04 F7
 
I've checked the MIDI_GET_FIRMWARE_VERSION on my brand new AXE II. To do that on a MAC, I just used AXE-EDIT and MIDI MONITOR, pressed on TEST CONNECTION in the MIDI setup window and monitored the MIDI IN and OUT messages on MIDI MONITOR.

Axe-Edit send:
F0 00 01 74 03 08 0A 00 00 04 F7

and receives
F0 00 01 74 03 08 05 07 0C F7

This is different to the way the AXE-FX use to work : Axe-Fx SysEx Documentation - Fractal Audio Systems Wiki

There are 2 extra bytes from previous version that don't look like checksum. So AXE II won't answer queries without the properly formed request.

I tried sending : F0 00 01 74 00 08 0A 00 00 07 F7 (without STANDARD model number) but the AXE-II did not respond.

The MIDI_GET_FIRMWARE_VERSION query format has changed so it won't work with STANDARD and ULTRA. Seems the only to way is to send the 2 versions of the query and see which one gets an answer to know what AXE is at the end of the line.

Hope that helps
 
Last edited:
CyberFerret said:
Did you mean in the structure of the SYSEX strings?
The other major change is that when you send values to the Axe-FX, they are now contained in a 3 byte block which is structured differently from the old 2 byte (hi/lo) segment on the Ultra. If I get some time in the next day or so, I will try and document that on the Wiki too...
Click to expand...

Had a look a the new message format, the values seem to be send in the following way for AMP1-BASS setting:
0,00 (min) --> 00 00 00
10,0 (max) --> 7E 7F 03
2.00 --> 33 66 00
2.01 --> 74 66 00
So for that type of parameter the rule seems to be ( Target value / Param range ) * ( 256 * 256 * 4). Number is expressed on 3 bytes and written with "reverse" byte order.

For the AMP-TYPE param (77 amp models):
0 --> 00 00 00
76 --> 4C 00 00
The lower (but first in reverse order) byte just stores the value (converted in hexa).

According to Axe-FX SysEx Messages (from GM Arts) that was not the way it used to work on the AXE-FXs (ONEs).
 
Last edited:
PALYGAP said:
Had a look a the new message format, the values seem to be send in the following way for AMP1-BASS setting:
0,00 (min) --> 00 00 00
10,0 (max) --> 7E 7F 03
2.00 --> 33 66 00
2.01 --> 74 66 00
So for that type of parameter the rule seems to be ( Target value / Param range ) * ( 256 * 256 * 4). Number is expressed on 3 bytes and written with "reverse" byte order.

For the AMP-TYPE param (77 amp models):
0 --> 00 00 00
76 --> 4C 00 00
The lower (but first in reverse order) byte just stores the value (converted in hexa).

According to Axe-FX SysEx Messages (from GM Arts) that was not the way it used to work on the AXE-FXs (ONEs).
Click to expand...

Yes, the old Standard/Ultra devices used to store the parameter values on *most* knobs as 0-254. This was split into two bytes, XX YY where XX was the lowest 4 bits of the value, and YY was the highest 4 bits. Pretty simple.

The new Axe-II now has more granular control over *most* knobs, with the values going from 0-65534. This requires a full 16 bits to store. The problem is that the MIDI specifications means you can only transmit values using 7 bits as the highest bit of each byte must be a zero.

To get around this, the Axe-II uses THREE bytes to transmit the values XX YY ZZ where XX is the lowest 7 bits of the data, YY is the 8th to the 14th bit of the data, and ZZ is the remaining top two bits of the data.

So, if you had the value 52421 on a knob, then this would be represented by the 16 bits: 1100110011000101

If you split this into segments of length 2/7/7 to store in ZZ/YY/XX: 11 0011001 1000101

So XX gets the last segment: 01000101
And YY gets the middle segment: 00011001
And ZZ gets the first segment: 00000011

You will also have to back-calculate the respective knob values to the 16 bit values. For example, a knob that goes from 0 - 10, 0 would of course be 0, but 10 would be 65534. From there, you would work out that 5 is 32767 and 7 would be about 45871 etc.
 
Last edited:
Sounds like it's going to be quite a bit of work to detect and use an Axefx2, especially since I have an Ultra, and no budget to get a 2 yet.

It's good however that I have a completely software version of the controller, so I can get others to test the Axefx2 compatibility even if I don't have the hardware.

On top of that I'm working towards supporting LED rings / encoders, for EXTERN1-8 which update the current setting when you switch patches. All the low level code is done/working, it's just propagating the changes up into the higher level foot controller code. No rest for the wicked!
 
Thanks CyberFerret for the clear explanation. I though that when it came to SysEx it was all "frestyle" as long as you where in between the F0 and F7 tags.

Ok, so in fact 2 bytes to store 128 values + 1 byte to store 4 values : that would make 65536 going from 0 to 0-65535? Actually the maximum value I can see is 7E 7F 03 (65534), not sure why that is.

For the AXE II, it seems all numerical values use the 3 bytes coding scheme and all modal (say AMP1-TYPE) use only the first of the three byte (up to now) to store the value (that is enough t store up to 128 values).

I have tried the parameters change with the checksumED messages and that work great. Going through BOME' MIDI TRANSLATOR PRO on my MAC, I am now able to tune my AXE II presets from a BCR2000. The other cool thing is that the sound pops or jitters do no occur for most parameter (a few still do it). So the "GUTS" parameter of the AMP block, SAG, DEPTH, ..., can be nicely tweaked and I can hear the continuous change in tone and select the one I like.

FRET, I am planning to do a software detection of the AXE version at the end of the MIDI cable. I have the new AXE II and still have my AXE ULTRA (soon to be sold). I'll let you know if I get somewhere.
 
Last edited:
CyberFerret said:
Yes, the old Standard/Ultra devices used to store the parameter values on *most* knobs as 0-254. This was split into two bytes, XX YY where XX was the lowest 4 bits of the value, and YY was the highest 4 bits. Pretty simple.

The new Axe-II now has more granular control over *most* knobs, with the values going from 0-65534. This requires a full 16 bits to store. The problem is that the MIDI specifications means you can only transmit values using 7 bits as the highest bit of each byte must be a zero.

To get around this, the Axe-II uses THREE bytes to transmit the values XX YY ZZ where XX is the lowest 7 bits of the data, YY is the 8th to the 14th bit of the data, and ZZ is the remaining top two bits of the data.

So, if you had the value 52421 on a knob, then this would be represented by the 16 bits: 1100110011000101

If you split this into segments of length 2/7/7 to store in ZZ/YY/XX: 11 0011001 1000101

So XX gets the last segment: 01000101
And YY gets the middle segment: 00011001
And ZZ gets the first segment: 00000011

You will also have to back-calculate the respective knob values to the 16 bit values. For example, a knob that goes from 0 - 10, 0 would of course be 0, but 10 would be 65534. From there, you would work out that 5 is 32767 and 7 would be about 45871 etc.
Click to expand...

Hi CyberFerret this is a very useful informatiom , so I was trying to control the Amp gain parameter of Axe fx 2 and I program my midi controller(Novation zero mk2) like that [F0 00 01 74 03 02 6A 00 01 00 zz yy xx 01 ?? F7] but I still can't figure out how to program the midi controller to calculate this second last checksum byte. Is there any way to avoid that byte ? Or is there any controller tha can do that ?
 
prs22 said:
Hi CyberFerret this is a very useful informatiom , so I was trying to control the Amp gain parameter of Axe fx 2 and I program my midi controller(Novation zero mk2) like that [F0 00 01 74 03 02 6A 00 01 00 zz yy xx 01 ?? F7] but I still can't figure out how to program the midi controller to calculate this second last checksum byte. Is there any way to avoid that byte ? Or is there any controller tha can do that ?
Click to expand...

Without knowing about the programmability of the MKII I would doubt that it would be possible to do this calculation dynamically.
Is attaching a modifier to the amp block out of the question?
If so, then I guess the only alternative to calculating the checksum would be to somehow have a prepopulated list of all the values, including the checksum :)
 
You must log in or register to reply here.
Back
Top Bottom