Preset (@M Dr.Who) causing 'Manage Presets' save operation to fail.

playmusic

Inspired
Ran into a solvable issue last night. Sharing it in case anyone else encounters it. I went to overwrite my current presets with a fresh backup I had made just to make sure I picked up any new block changes in the 8.00 firmware. Did this by creating a backup. Browsing to it in the 'Manage Presets' screen and then copy & pasting it over my current presets. And then hitting 'Save' to overwrite my current presets with the backup.

Everything worked fine until the save hit a preset I had downloaded "@M Dr.Who", I believe from Axe-Exchange, although it could have been from Gift Of Tone. Every time the save hit this preset, it would continue to proceed through the rest of the presets designated to be saved. However, the remaining presets with red dots next to them following and including "@M Dr.Who" were not overwritten/saved as they should have been in normal save execution. The red dots did not go away. The red dots disappear sequentially in normal save behavior as each preset is successfully overwritten. Also, at the end of the 'Save' the save button was still active, and if I hit it, it would attempt again to save all the presets with red dots that should have already saved successfully. Somewhat mystifying. Additionally, the editor would start reporting communication errors and start a process of rereading the presets that was abnormally long and had to be interrupted.

Started troubleshooting at the preset "@Dr_Who" where the save started failing (red dot not going away). When I selected the preset, it would jump immediately from 85% to 100% CPU and lock up the FM9 completely. Restarting the FM9 after that brought up the "@M Dr.Who" preset which immediately locked up the device so I could not select a different preset.

Solution: Restarted the FM9 while holding down the 'Home' button which brings you to that special uninitialized preset "00". A lifesaver when the FM9 is starting on a preset that is locking it up. That allowed me to go into the 'Manage Presets' screen and, without selecting it, right-click and use the 'Clear' selection to clear that preset. I could I believe, alternatively, have overwritten the '@M Dr.Who' preset with that "00" preset. After clearing the problem preset, normal save operation in 'Manage Presets' was restored. So, if anyone runs into this behavior, look for where the save starts failing and investigate that preset. If you can modify it to use less CPU, great. If everything locks up so that is not an option, you can clear it, as I had to.

Even if the preset causing the problem is not selected, a problematic preset using too much CPU, can cause a multiple preset save operation in 'Manage Presets' to fail in a manner that is not straightforward and somewhat confusing, with no error message. The red dots to the left of the presets still remaining after a save will alert you that your presets have not been properly saved. No problem, just clear or reduce CPU usage in the preset causing the issue.
 
Last edited:
Restarted the FM9 while holding down the 'Home' button which brings you to that special uninitialized preset "00"
I've done this (for the first time) multiple times this week, because of the austin buddy presets. Would be cool if there was some kind of 'inspect/edit-only' mode which would not process the audio signal, but would allow to delete blocks and save the presets. If anyone knows an existing wish thread, let me know... also if you have a solution (except for buying an Axe Fx III ;)).
 
I've done this (for the first time) multiple times this week, because of the austin buddy presets. Would be cool if there was some kind of 'inspect/edit-only' mode which would not process the audio signal, but would allow to delete blocks and save the presets. If anyone knows an existing wish thread, let me know... also if you have a solution (except for buying an Axe Fx III ;)).

Agree, it would be nice to have the code "trap" a failed save operation in the 'Manage Presets' and generate a "Save Failed" dialog. I guess the same thing applies to selecting a preset that uses too much CPU. More optimal for that preset to be de-selected or better yet as you suggest, place it in a mode where it can be edited, with a warning message about excessive CPU usage, than to allow the system to lock up. Have to think that Fractal has already considered that already though and that there is some sort of roadblock to implementing it.
 
Last edited:
Back
Top Bottom