Third-Party MIDI Spec

Bit 0 - off or on = 0 or 1
Bit 1 - off or on = 0 or 2
Bit 2 - off or on = 0 or 4
Etc
Make sure you’ve seen the “error” in an analyser before raising as a bug... it *might* just might be your code. ;-)

I’ve done the decoders for the looper, and didn’t see any issues, but that was a couple of days ago.
 
Bit 0 - off or on = 0 or 1
Bit 1 - off or on = 0 or 2
Bit 2 - off or on = 0 or 4
Etc
Make sure you’ve seen the “error” in an analyser before raising as a bug... it *might* just might be your code. ;-)

I’ve done the decoders for the looper, and didn’t see any issues, but that was a couple of days ago.

I don't know, that is a bug. Maybe it is. I send a Status-Dump message to the Axe-FX III and get back never a message where bit 0 is set! I dump out all the messages I receive. Maybe you can check it in the next time?
 
@FractalAudio i think there is a bug here. It appears the RECORD state bit in the response message is inverted. So when record is activated it is setting bit0 to zero, where i think it should be 1. I haven't tested the other looper bits just yet (no pun intended). Going to do that now.
 
@FractalAudio i think there is a bug here. It appears the RECORD state bit in the response message is inverted. So when record is activated it is setting bit0 to zero, where i think it should be 1. I haven't tested the other looper bits just yet (no pun intended). Going to do that now.

Hit RECORD get 0x00 (expected 0x01)
Hit PLAY get 0x02 (expected 0x02)
Hit PLAY again get 0x02 (AxeFX screen clears PLAY expected 0x00)
Hit PLAY again get 0x00 (expected 0x02)
Hit UNDO get 0x02 (i can press undo many times always getting 0x02 which i would expect here)
Hit ONCE get 0x0A (as expected)
It is impossible to know (without polling) that the Looper has Stopped after the ONCE command. (would be nice to get an unsolicited LooperState response
Hit REVERSE get 0x10 (as expected)
Hit PLAY get 0x10 (expected 0x12)
Hit HALF get 0x10 (expected 0x22)

Think this needs a little look at Cliff. Cheers.
 
Hit RECORD get 0x00 (expected 0x01)
Hit PLAY get 0x02 (expected 0x02)
Hit PLAY again get 0x02 (AxeFX screen clears PLAY expected 0x00)
Hit PLAY again get 0x00 (expected 0x02)
Hit UNDO get 0x02 (i can press undo many times always getting 0x02 which i would expect here)
Hit ONCE get 0x0A (as expected)
It is impossible to know (without polling) that the Looper has Stopped after the ONCE command. (would be nice to get an unsolicited LooperState response
Hit REVERSE get 0x10 (as expected)
Hit PLAY get 0x10 (expected 0x12)
Hit HALF get 0x10 (expected 0x22)

Think this needs a little look at Cliff. Cheers.
You have to continually poll the state. The state reported when you remotely press a button is the current state. It can take up to 100 ms for the state to actually change. You should poll the state at ~10 Hz.
 
also when PLAYing and then pressing the RECORD, the AxeFX screen shows REC PLAY and OVERDUB lit up. The bitmask records PLAY and OVERDUB, but not RECORD. Should it?

Thanks for the previous clarification Cliff (@FractalAudio). Can you explain this. Thanks
 
Last edited:
Is it no longer possible to set effect parameters by sysex?

I built a controller that I used on my Axe-FX IIXL+ that could control the amp drive, master, etc... through sysex messages. I preferred setting the knob position via sysex instead of continuous controller because the controller won't "let go" if you want to change it from the screen, preset or x/y (now channel)

I updated my code with the new 0x10 model and I think I have the effect ID for AMP 1 picked correctly. Initially I used the ID_DISTORT1 value but also tried just setting it to 0x3A (If I'm counting correctly from the document). Unfortunately, I'm not getting the reaction from the axeIII that I expect.

This code worked on the Axe-FX II, so I'm thinking something else changed other than just the model and the effect ID.

I'm thinking I should be sending: header [ F0 00 01 74 10] set [02] amp 1 [3A 00] parameter 1 [01 00] value [XX YY ZZ] footer [checksum][f7]

Am I missing it or is this no longer possible?
 
Is it no longer possible to set effect parameters by sysex?

I built a controller that I used on my Axe-FX IIXL+ that could control the amp drive, master, etc... through sysex messages. I preferred setting the knob position via sysex instead of continuous controller because the controller won't "let go" if you want to change it from the screen, preset or x/y (now channel)

I updated my code with the new 0x10 model and I think I have the effect ID for AMP 1 picked correctly. Initially I used the ID_DISTORT1 value but also tried just setting it to 0x3A (If I'm counting correctly from the document). Unfortunately, I'm not getting the reaction from the axeIII that I expect.

This code worked on the Axe-FX II, so I'm thinking something else changed other than just the model and the effect ID.

I'm thinking I should be sending: header [ F0 00 01 74 10] set [02] amp 1 [3A 00] parameter 1 [01 00] value [XX YY ZZ] footer [checksum][f7]

Am I missing it or is this no longer possible?
No longer officially possible... the only "supported" features are in the third party spec at the top of this thread.
 
No longer officially possible... the only "supported" features are in the third party spec at the top of this thread.

I was afraid of that.

Is there some way that I'm not thinking of to make a controller modifier "let go" other than manually removing it from the parameter its hooked to?
 
Die I missunderstood the documentation? The response from the Axe-FX III is there described as setted bits. So if the Axe-FX sends a "2" then the Bit 1 is set! That means "Play". Bit 2 is overdub! Is this right or did I missunderstood the MIDI-Sysex-Spec?

Ya I think you're correct. The return values don't seem to be right and the current midi spec probably needs to be revised. Some values are getting doubled. Both play and record are sending duplicate return values. Stopped state doesn't have a bit assignment in the midi spec. Didn't matter if I used the front panel or sent a sysex command, same results. I've attached a spread sheet of the values I was seeing using midi-ox and a recommendation for the midi spec. Of course I've could have interpreted this all wrong...

Edit
Did some research on what Bit 0 meant and revised my spread sheet. The midi spec is ok but the return values are definitely off. Appears that the record button (flashing or solid) does not activate Bit 0 and half-speed is activating Bit 4 instead of Bit 5 per the midi spec.
 

Attachments

  • AxeFxIIILooperSysex 1.3FW1.15Revised2.zip
    10.5 KB · Views: 15
Last edited:
Ya I think you're correct. The return values don't seem to be right and the current midi spec probably needs to be revised. Some values are getting doubled. Both play and record are sending duplicate return values. Stopped state doesn't have a bit assignment in the midi spec. Didn't matter if I used the front panel or sent a sysex command, same results. I've attached a spread sheet of the values I was seeing using midi-ox and a recommendation for the midi spec. Of course I've could have interpreted this all wrong...
I think Cliff's response about having to Poll the state answers a lot of the "why is it wrong when it first responds". Having implemented a polling test, most of the status codes seem to hang together correctly. Im about to raise a BUG report on the HALFSPEED coding and whether the RECORD should be flagged in the status when overdub mode is enabled.
 
Could I ask for some explanation of why the RECORD (for example) doesn't immediately come back with the correct state code in the response. I feel this isn't "right". I've implemented a polling module in my code (like Cliff suggested) which activates when a looper state is indicated and stops when looper state is indicated at zero. Unfortunately, because the RECORD doesn't return a non zero state in the first response, my module won't start polling. I would have thought that would be a good practice to only do the polling when required, but because the RECORD (for example) doesn't return the first positive status, my loop poller doesn't know the looper has effectively started.
 
I think Cliff's response about having to Poll the state answers a lot of the "why is it wrong when it first responds". Having implemented a polling test, most of the status codes seem to hang together correctly. Im about to raise a BUG report on the HALFSPEED coding and whether the RECORD should be flagged in the status when overdub mode is enabled.
I'm not so sure about that. The return response from setting the looper state thru sysex and manual query thru midi-ox are yielding the same results long after one of the looper button is engaged. Its not a polling issue if I keep getting back the same response. I think it will be obvious to fractal once they take a close look at it.
 
I'm not so sure about that. The return response from setting the looper state thru sysex and manual query thru midi-ox are yielding the same results long after one of the looper button is engaged. Its not a polling issue if I keep getting back the same response. I think it will be obvious to fractal once they take a close look at it.
More than likely! :);)
 
Pretty sure I figured out what is wrong with the Looper return messages. I revised my previous post about it. Axe-Fx III Third-Party MIDI Spec
Yes. I raised two bug threads about these issues. The half speed is definitely a bug. The record button indication is more about intention of the design, however I would be more in favour of a positive response code from the request to record, even if there was another bit indicating “record armed” to cope with (the great) threshold feature. We can but only wait for @FractalAudio to chime in.
 
Noticed a few "errata" on the 3rd party midi spec. Rev 1.3

1) Get/Set Channel, "dd is the channel (0-3)" should read "dd is the channel (0-5)"
2) Status Dump, "...currently the maximum number of channels for any effect is 3)." should read "...for any effect is 5)."

for interpretation reasons... 0..5 = A..F
(2) is slightly misleading because it means the maximum *value* for this field is 5 --- 0..5 = 6 channels

Most blocks have only 4 channels... but the MUXes have 6. I'm not aware of any other effects with more than 4 channels.
 
Back
Top Bottom