It's taking 20+ loops of this function before is actually reads teh Preset Name.
I was going to mention this earlier in the thread, but I left it, as I know it's easy to get swamped with detail when you're trying to learn a lot of new stuff.
If you take a step back, and (using MIDI-OX) study the general flow of midi messages which originate from the Axe Fx when you do things like:
1. Use the rotary control to change presets
2. Turn effects blocks on and off
3. You send a program change message to the Axe FX
What you will see is that there is a predictable, but fairly loosely coupled set of Sysex messages being sent. In an ideal world, your foot controller would respond to the Axe FX telling it that a new Preset has been activated due to the user changing the rotary control, just as it would a midi foot controller sending it a program change message. Equally, if the user went to the layout screen and used the FX bypass button on a particular module, you'd expect the foot controller to seamlessly sync the Instant Access (IA) state for that module. That's how the MFC101 works.
What this means, is that you are far better off decoupling your handling of MIDI messages so that your program is not quite so stateful. More or less, you are currently doing this:
1. User presses Footswitch for preset 1
2. Controller sends program change for preset 1
3. Controller sends Read Preset Name and waits for response
4. Controller updates Screen with preset name
5. Normal processing resumes
You'd be better off doing this:
1. User presses footswitch for preset 1
2. Controller sends program change for preset 1
3. Main processing loop resumes
.
.
.
4. Controller receives sysex packet from Axe Fx indicating a new preset has been loaded up
5. Controller sends "Read Preset Name" sysex packet
6. Normal processing loop resumes
.
.
.
7. Controller receives Preset name sysex from Axe Fx
8. Controller updates display
9. Normal processing loop resumes
.
.
Can you see the difference ? In the second scenario, the controller is always in the main loop polling the footswitches and seeing if there's any new data incoming from the Axe Fx - it's never stuck waiting for messages. It also responds equally to changes made on the Axe front panel as it does the foot controller itself.
Yes, there is the case where you need some kind of time check to make sure that you get a response before too much time has elapsed (pretty much what happens with an MFC101 when it gives the dreaded AxeFx name timeout) but this is not an inline delay where nothing else happens, it is a timer count running alongside the rest of the processing.
It's a bit late and I'm off to bed now, but I thought I'd drop this in as some food for thought. I know you're saving up a load of changes for V2 of your code, so as a simple suggestion for fixing what you have now, I would suggest that when you want to call ReadPSName() you should set a flag to indicate that you are waiting for a name, reset a counter, then send the Read PresetName sysex message. In your sysex handler, when you get a preset name message coming in, you update the screen and reset the flag. In your main loop, if the counter reaches a certain value, and the flag is set, then you know the read preset name has timed out. Ideally, you don't want a simple counter, rather you want to use the timer ticks - but my mind has gone blank and I can't think how to do this on Arduino right now.
Hopefully this makes some sense. Shout back if you think I'm talking nonsense !