Troubleshooting help needed

Yep, I'll chime in. The short answer is that it was a "bug" in MFC-Edit. I quote the "bug" because it was intentionally coded that way, but based on incorrect or outdated information. MFC-Edit is very strict about what it will and will not ingest. The Mk I/II dumps are not the same size or content as the Mk III dumps, further complicated by the contents of 3.0, 3.1,3.2,3.5,3.6 and 3.7 being different content. MFC-Edit checks the Equipment Model and the Firmware version to know how to extract the data from the dump. I had learned some time ago that after 3.0 there'd be no new firmware features for the Mark I/II, so MFC_Edit did not test for FW 3.5 and above on the Mk I/II. So it misidendified the data as invalid because it as a Mk I/II dump but with a 3.7 FM and rejected it as invalid. While I wasn't up to speed on the new firmware for the Mark I/II, I commend FAS for continuing to keep it FW current with the Mark III.

I've come up with some additional checks that I can add to the code so that it doesn't rely solely on the Model and Firmware information to determine which data stream version it is looking at. It might slow down the opening of a sysexdump by a millisecond or two but well worth it to save users the grief that Mike just endured.

It may be a week or two - I really need to test it with a lot of combinations of Model/FW before the new version is available.
 
Curious how that affected the behavior of MFC and Axe when Edit wasn't involved? I though he couldn't get anything working at all? A few others seem to have the same issue.
 
Curious how that affected the behavior of MFC and Axe when Edit wasn't involved? I though he couldn't get anything working at all? A few others seem to have the same issue.

Chris, to be specific- I had a few issues going on.
I updated MFC to FW 3.07, installed the editor, updated axe to beta 18, added an EV1, updated axe edit, updated to Cab Lab 3 all on the same day. I know....it's not recommended, but my schedule is what it is and I went for it.
I noticed the issue with mfc edit right away and spent some time trying to work the problem....including creating a new file in mfc edit and sending to the 101 (i thought i corrupted the 101 by doing this). It wasn't till later- actually at a gig that i noticed an odd behavioral issue with some of my presets on the axe.
My mistake in troubleshooting was to focus on the mfc as the issue- turns out it was more than that, and an embarrassingly simple one. Yes the editor had a bug as noted above...but as you correctly identified, the odd behavior of the axe was not caused by an mfc issue; I realized that somehow my cpu usage had krept up to 94% in 2 or 3 of my axe presets presumably when updating to the beta. Honestly, in a few years of owning the axe, ive never had a cpu limit issue so it was the last thing I would have looked for. I would not have suspected it to cause the odd behavior I was experiencing...I may have been tipped off by clipping or the signal cutting out like others have experienced. In my case it was obscuring the bidirectional communication.
So, it may help others to look at their CPU usage within a preset if they are having similar issues- and note to self- dont make so many changes at once, it really clouds the troubleshooting efforts.
 
got it! thanks so much for sharing that information, it really helps add to the collective knowledge base when similar issues arise.

there's a lot going on and many "moving parts" so it's easy to skip some simple solutions when going for the huge ones :) believe me, i've done it all!
 
Back
Top Bottom