Axe-FX II sysex checksums

Home Forums General Programming Axe-FX II sysex checksums

Viewing 15 posts - 1 through 15 (of 15 total)
  • Author
    Posts
  • #71313
    sumitagarwal
    Participant
    • Topics: 3
    • Replies: 11
    • Total: 14

    Hi guys, I am trying to program a panel to control the Axe-FX II and I’m having trouble with the checksum byte.

    The documentation for the Axe-FX II checksum is here: https://wiki.fractalaudio.com/axefx2/index.php?title=MIDI_SysEx#MIDI_SysEx:_calculating_the_SysEx_checksum

    I don’t know how to represent that type of checksum in Ctrlr.

    The sample command I’m using is this one:
    F0 00 01 74 06 02 6A 00 27 00 00 00 00 01 4D F7 (this turns off the Bright switch on Amp block 1)

    In that sample, you can see the checksum byte is 4D.

    I have tried both Roland and Waldorf checksum types, and it looks to me that I should be counting 14 bytes, but neither checksum type gives me a result of 4D.
    Here is the formula I’m trying to use:
    F0 00 01 74 06 02 6A 00 27 00 00 00 00 01 t14 F7

    #71314
    dasfaker
    Keymaster
    • Topics: 80
    • Replies: 793
    • Total: 873
    • ★★★

    Weird sysex implementation.

    I just messed with the example provided on the docs, and this is not a Roland or Waldorf checksum. It uses XOR operations (don’t know what they are and how they work). But with a XOR calculator online, I get to the expected result:

    F0 00 01 74 03 0F F7

    You need to do 0xF0 ^ 0x00 ^ 0x01 ^ 0x74 ^ 0x03 ^ 0x0F = 0x89

    I get to this result by:
    F0 ^ 00 = F0
    F0 ^ 01 = F1
    F1 ^ 74 = 85
    85 ^ 03 = 86
    86 ^ 0F = 89

    Now you remove the leftmost bit of the result and add 7f, so the end message is F0 00 01 74 03 0F 09 F7, a byte longer.

    The doc example doesn’t have checksum, it is added later. Does your example command have checksum (4D) or do you have to calculate from the sysex string and add it later?

    Doing the above operations with your formula, I get as result:

    F0 ^ 00 ^ 01 ^ 74 ^ 06 ^ 02 ^ 6A ^ 00 ^ 27 ^ 00 ^ 00 ^ 00 ^ 00 ^ 01 = CD
    (removing leftmost bit C would give 0D as checksum) not taken into account byte 4D,

    F0 ^ 00 ^ 01 ^ 74 ^ 06 ^ 02 ^ 6A ^ 00 ^ 27 ^ 00 ^ 00 ^ 00 ^ 00 ^ 01 ^ 4D = 80
    (removing leftmost bit 8 would give 00 as checksum) taken into account byte 4D.

    So you could try both formulas (little hope they work):
    F0 00 01 74 06 02 6A 00 27 00 00 00 00 01 0D F7
    F0 00 01 74 06 02 6A 00 27 00 00 00 00 01 4D 00 F7

    • This reply was modified 5 years, 7 months ago by dasfaker.
    • This reply was modified 5 years, 7 months ago by dasfaker.
    • This reply was modified 5 years, 7 months ago by dasfaker.
    #71317
    sumitagarwal
    Participant
    • Topics: 3
    • Replies: 11
    • Total: 14

    Thanks dasfaker! I’ll try your formulas but yes doesn’t seem like it will match.

    In the example I provided with the 4D checksum, I had grabbed that example command by monitoring the output of the Axe Edit desktop application, which I believe calculates the checksum for each command and appends it before sending.

    #71318
    dasfaker
    Keymaster
    • Topics: 80
    • Replies: 793
    • Total: 873
    • ★★★

    Then something is wrong with my calculations, as I get 0D instead of 4D. Could you post a shorter example?

    #71320
    sumitagarwal
    Participant
    • Topics: 3
    • Replies: 11
    • Total: 14

    Hrm, maybe try this? I don’t know what this message means, but its much shorter:
    F0 00 01 74 06 2A 29 F7

    I think that’s a response message back *from* the Axe-FX II, but per the documentation the response messages also use a checksum which I would assume are calculated the same way.

    #71338
    dasfaker
    Keymaster
    • Topics: 80
    • Replies: 793
    • Total: 873
    • ★★★

    Ok, there was a error with the method used, but I still don’t get the exact checksum.

    Let’s go with you first message: F0 00 01 74 06 02 6A 00 27 00 00 00 00 01 4D F7

    Once you XOR all the bytes (F0^00^01^74^06^02^6A^00^27^00^00^00^00^01) the result is CD

    Now the error: you must add CD to 7F (CD + 7F = 14C) and remove the leftmost bit: 14C –> 4C

    The checksum we get is 4C, but it should be 4D

    With the last message you provided, I get the same result:
    F0 00 01 74 06 2A 29 F7
    F0^00^01^74^06^2A = A9 — A9 + 7F = 128 —> checksum = 28 and it should be 29.

    We are really close.

    #71339
    sumitagarwal
    Participant
    • Topics: 3
    • Replies: 11
    • Total: 14

    Thanks a ton for your effort in helping crack this! Unfortunately it seems like quite a bit about the Axe-FX is somewhat unusual or nonstandard. A shame since its a fantastic piece of equipment that is used by many of the most famous guitarists in the world.

    Anyway, I’m thinking maybe the below will be useful reference since it shows how the checksum ends up with only one byte changed?

    Turn Amp 1 bright switch on
    F0 00 01 74 06 02 6A 00 27 00 01 00 00 01 4C F7
    Turn Amp 1 bright switch off
    F0 00 01 74 06 02 6A 00 27 00 00 00 00 01 4D F7

    #71340
    dasfaker
    Keymaster
    • Topics: 80
    • Replies: 793
    • Total: 873
    • ★★★

    Yes, it doesn’t seem to be an easy implementation.
    The bad news is that (not that bad in fact), as far as I know, there’s no automatic checksum calculation of this kind in Ctrlr’s sysex formulas, it should be all done with LUA.

    Knowing that our calc give us just 1 figure less, just adding 1 to the result could be ok.

    I still don’t know how to calc XOR operations in LUA.

    #71347
    sumitagarwal
    Participant
    • Topics: 3
    • Replies: 11
    • Total: 14

    Ok, there was a error with the method used, but I still don’t get the exact checksum.

    Let’s go with you first message: F0 00 01 74 06 02 6A 00 27 00 00 00 00 01 4D F7

    Once you XOR all the bytes (F0^00^01^74^06^02^6A^00^27^00^00^00^00^01) the result is CD

    Now the error: you must add CD to 7F (CD + 7F = 14C) and remove the leftmost bit: 14C –> 4C

    The checksum we get is 4C, but it should be 4D

    With the last message you provided, I get the same result:
    F0 00 01 74 06 2A 29 F7
    F0^00^01^74^06^2A = A9 — A9 + 7F = 128 —> checksum = 28 and it should be 29.

    We are really close.

    Hrm, I tried using the calculator here:
    http://www.miniwebtool.com/bitwise-calculator/?data_type=16&number1=a9&number2=7f&operator=AND

    Your XOR to get a result of A9 seems correct. Its the last step where something isn’t right in your calculation.

    I used the tool to AND A9 to 7F and got the expected 29

    #71351
    dasfaker
    Keymaster
    • Topics: 80
    • Replies: 793
    • Total: 873
    • ★★★

    I used this online calculator and got 128 !!

    • This reply was modified 5 years, 7 months ago by dasfaker.
    #71356
    sumitagarwal
    Participant
    • Topics: 3
    • Replies: 11
    • Total: 14

    This is how it looks to me

    Attachments:
    You must be logged in to view attached files.
    #71358
    sumitagarwal
    Participant
    • Topics: 3
    • Replies: 11
    • Total: 14

    Oh, I see what happened in your link. That link was for ADD not AND

    #71359
    dasfaker
    Keymaster
    • Topics: 80
    • Replies: 793
    • Total: 873
    • ★★★

    LOL, i thought it was the same!!

    #71441
    sumitagarwal
    Participant
    • Topics: 3
    • Replies: 11
    • Total: 14

    So… I guess in order to implement my own checksum calculations and attach that to a modulator, I should be using “Called to calculate the MIDI value to send”?

    Can anyone point out a sample panel that does that? So far for reference I’ve been poking through the Prophet 6 panel and not seeing anything like that.

    #71442
    sumitagarwal
    Participant
    • Topics: 3
    • Replies: 11
    • Total: 14

    Well, this was my first time writing Lua (I’m not a programmer by any stretch of the imagination). This is what I came up with for the Axe-FX II checksum, and… it works!!

    y = bit.bxor(0xF0, 0x00, 0x01, 0x74, 0x06, 0x02, 0x6A, 0x00, 0x27, 0x00, numericModulatorValue, 0x00, 0x00, 0x01)
    n = bit.band(y,0x7F)
    m = CtrlrMidiMessage({0xF0, 0x00, 0x01, 0x74, 0x06, 0x02, 0x6A, 0x00, 0x27, 0x00, numericModulatorValue, 0x00, 0x00, 0x01, n, 0xF7})

Viewing 15 posts - 1 through 15 (of 15 total)
  • The forum ‘Programming’ is closed to new topics and replies.
There is currently 0 users and 78 guests online
No users are currently active
Forum Statistics
Threads: 2,495, Posts: 17,374, Members: 77,605
Most users ever online was 12 on January 22, 2019 3:47 pm
Ctrlr