Arduino Axe-Fx control library

Piing said:
Got it!

#ifdef TESTING_SETUP
_setupMode = true;

I feel so stupid once I've found it :p
Click to expand...

Yes it's designed that you just recycle power once you have finished. You hold any button down on power up to enter setup mode, then restart. I haven't fully finished that feature either. It works for basic button presses though.

I should not really have released that repo as it's a work in progress. I have since made it private, but you are welcome to keep using the code you have.
 
Piing said:
Got it! Just stored the names and created a recall screen.
Thank you
Click to expand...

That looks like a hole in the documentation. You have the right idea though; in the tuner status callback, you will have to tell your display code that it's time to redisplay its current data. The library relies completely on callbacks and tries to avoid storing much state, so the implementing code is responsible for maintaining app state. This gives you more flexibility rather than having to follow the flow logic of a library.
 
Last edited:
Piing said:
@tysonlt I've built a minimalist setup with one Arduino Mega, a 1.8" ST7735 and a CD74HC4067 for playing and learning with your AxeHandle program :)

I don't even need buttons; I just touch the multiplexer terminals with a bare wire connected to ground, and someing is!

The mess of resistors are voltage dividers to convert the arduino 5V logic signals to 3.3V for my "KMR-1.8" cheap version of the ST7735 display. It took me a couple of days to figure out that requirement. It works fine with the ST7735_t3.h library, though.

Axe-Controller-01.jpg


I am stuck into the SETUP routine. I can assign functions to the buttons, but I cannot go out of that loop.

"Hold MODE to save" saves the button function and goes back to the buttons setup (I assume that MODE is button 5)
"Hold TAP to cancel" goes back to the buttons setup (I assume that TAP is button 10)

Could you confirm if that is a working release? jut to be sure, before I spend more time reverse-engineering for debugging.
Click to expand...

Looks great mate! Thrilled to see someone is using the library!

For making the button layouts, the best way for now is probably to just modify one of the Layout classes. That way you can make them do whatever you want. I should stress that the AxeHandle project was just something I was doing for my own controller, I haven't really focused on making it easy to use for others. It is by no means the only (or even the ideal) way to use the library. If you want to use it for learning, I would consider starting your own version fresh, using the AxeHandle stuff just as a reference on how to do specific things. For example, you could simplify the button handling code.
 
There is some issue with the FetchAllScenes example included at the library.

The data is corrupted when there is a fast preset change.

This is the correct result, when there is a pause between preset changes (current selected scene is #8):

onPresetChange()
=====================
Preset: 384 - This is the name of this preset
Scene: 8 - This is the name of Scene --- 8
=====================

++++++++++++++++++++++++

onSceneName(): 1: This is the name of Scene --- 1
onSceneName(): 2: This is the name of Scene --- 2
onSceneName(): 3: This is the name of Scene --- 3
onSceneName(): 4: This is the name of Scene --- 4
onSceneName(): 5: This is the name of Scene --- 5
onSceneName(): 6: This is the name of Scene --- 6
onSceneName(): 7: This is the name of Scene --- 7

And this is the result when the presets are switched fast (current selected scene is #8 but it returns #1, the scene that was selected at the previous preset. Scene #2 is missing and Scene #3 is corrupted):

onPresetChange()
=====================
Preset: 384 - This is the name of this preset
Scene: 1 - This is the name of Scene --- 1
=====================

onSceneName(): 8: This is the name of Scene --- 8
onSceneName(): 3: This is the nam⸮
onSceneName(): 4: This is the name of Scene --- 4
onSceneName(): 5: This is the name of Scene --- 5
onSceneName(): 6: This is the name of Scene --- 6
onSceneName(): 7: This is the name of Scene --- 7
 
Fast preset changes are a challenge for sure. It could be that the sysex messages are filling the serial input buffer before it can be read, but given the speed of the arduino this is unlikely. It is also possible that the axe is sending the sysex but then aborting mid-stream if it has to send a new message before current one is finished. This is also unlikely.

At the moment the lib deals with this by dropping stale messages and only responding to input related to the latest preset. I am able to spin the wheel on my axe without any corrupt data, but I have definitely noticed some funny stuff coming back in the past.

I have added sysex validation as suggested by @AlbertA to this branch: https://github.com/tysonlt/AxeFxControl/tree/sysex-checksum-validation but I am at work atm so I haven't run it against the axe. Please feel free to test it for me! Hopefully that will fix the issue.

Thanks for the feedback!
 
I would be grateful of any assistance reading the scene selected data from the Axe Fx IIXL. I am sending the sysex values 0xF0, 0x00, 0x01, 0x74, 0x06, 0x29, 0x7F, (0x55, 0xF7) the latter 2 bytes being the checksum and stop byte. Its says on the wiki fractal audio site "This is the same as SET_SCENE_NUMBER except you use 0x7F as the value for getting the scene number." However, the Axe Fx isn't responding to my request. Its fine for presets, names, cpu usage etc. Many thanks. John
 
blakeyhome said:
I would be grateful of any assistance reading the scene selected data from the Axe Fx IIXL. I am sending the sysex values 0xF0, 0x00, 0x01, 0x74, 0x06, 0x29, 0x7F, (0x55, 0xF7) the latter 2 bytes being the checksum and stop byte. Its says on the wiki fractal audio site "This is the same as SET_SCENE_NUMBER except you use 0x7F as the value for getting the scene number." However, the Axe Fx isn't responding to my request. Its fine for presets, names, cpu usage etc. Many thanks. John
Click to expand...

Hi John,
I attach a program I wrote for the Axe-FX II.

Here are the sysexes I was using for reading the preset name and number and the scene number:
Code: 
// sysex requests
// SET/ GET SCENE(COMMAND 0CH)
//Message format: F0 00 01 74 10 0C dd cs F7.
//dd is the desired scene. To query set dd = 7F.
//Returns:
//F0 00 01 74 10 0C dd cs F7; where dd is the current scene
byte GET_SCENE [9] ={0xF0, 0x00, 0x01, 0x74, 0x10, 0x0C, 0x7F, 0xC7, 0xF7};
byte RQSTNAME[6] = { 0x00, 0x01, 0x74, 0x03, 0x0F, 0x09 };
byte RQSTNUM[6] = { 0x00, 0x01, 0x74, 0x03, 0x14, 0x12 };
byte RQSTCC[6] = { 0x00, 0x01, 0x74, 0x03, 0x0E, 0x08 };
byte RQSTSCENE[6] = { 0x00, 0x01, 0x74, 0x03, 0x29, 0x2F };
 

Attachments

  • Axe2ParseNamesOK_00.zip
    4 KB · Views: 13
Piing said:
Hi John,
I attach a program I wrote for the Axe-FX II.

Here are the sysexes I was using for reading the preset name and number and the scene number:
Code: 
// sysex requests
// SET/ GET SCENE(COMMAND 0CH)
//Message format: F0 00 01 74 10 0C dd cs F7.
//dd is the desired scene. To query set dd = 7F.
//Returns:
//F0 00 01 74 10 0C dd cs F7; where dd is the current scene
byte GET_SCENE [9] ={0xF0, 0x00, 0x01, 0x74, 0x10, 0x0C, 0x7F, 0xC7, 0xF7};
byte RQSTNAME[6] = { 0x00, 0x01, 0x74, 0x03, 0x0F, 0x09 };
byte RQSTNUM[6] = { 0x00, 0x01, 0x74, 0x03, 0x14, 0x12 };
byte RQSTCC[6] = { 0x00, 0x01, 0x74, 0x03, 0x0E, 0x08 };
byte RQSTSCENE[6] = { 0x00, 0x01, 0x74, 0x03, 0x29, 0x2F };
Click to expand...

Thank you so much for your speedy reply.

So am I correct in thinking that the required sysex to query the set dd it is 7F. So for me on the Axe FX II it would be
0xF0, 0x00, 0x01, 0x74, 0x06, 0x0C, 0x7F, cs F7. ? I was under the impression that to request the set scene is was 0x29, you are using 0x0C ? I will try this. Many thanks once again. John
 
blakeyhome said:
Thank you so much for your speedy reply.

So am I correct in thinking that the required sysex to query the set dd it is 7F. So for me on the Axe FX II it would be
0xF0, 0x00, 0x01, 0x74, 0x06, 0x0C, 0x7F, cs F7. ? I was under the impression that to request the set scene is was 0x29, you are using 0x0C ? I will try this. Many thanks once again. John
Click to expand...

For 0x29 works fine for sending scene changes, for example

0xF0, 0x00, 0x01, 0x74, 0x06, 0x29, 01, cc, F7 (This would change to scene 1)
What doesn't work if I swap 01 for 7F to request a reply of the current scene number.

0xF0, 0x00, 0x01, 0x74, 0x06, 0x29, 0x7F, cc, F7
 
Have you managed to make it work? If I recall correctly, the sketch that I have posted was receiving all data correctly. That was one of the the first working version of my $50project. But now I don't have the Axe-FX II to test it.
 
Piing said:
Have you managed to make it work? If I recall correctly, the sketch that I have posted was receiving all data correctly. That was one of the the first working version of my $50project. But now I don't have the Axe-FX II to test it.
Click to expand...

No, I’m using my own code but can read everything else, names cpu etc. No problem changing scenes but not managed to get the reply saying what scene is selected.
 
I did eventually manage to get this to work, I am not sure what I was doing wrong. I think probably a silly mistake. Another question if I may. Does anybody know how to query the bypass state of a block. For example with a preset loaded is delay1 on or bypassed ?
 
axifist said:
That surprises me to be honest. What could be the reason for this?
Click to expand...

From what I saw, it seems that another message can start before the previous one finished, so you don't get the sysex end byte. There were also a number of cases where even if the message was correct, the numbers coming back for string, note, etc. were out of bounds.

Keep in mind that the Axe send a LOT of messages when the tuner is on, so it is probably filling up the RX buffer on the arduino, and the ring buffer rotates back to the start, overwriting the sysex data. As for the bad values - who knows? Library error?
 
Interesting! Thanks for the explanation. Do you happen to know if the III sends more / larger SysEx data per second than the II (and Ultra)? Because with the Ultra I've never seen an issue like that.

All the more reason to use checksums! Well done to put them in your library!! :)
 
You must log in or register to reply here.
Back
Top Bottom