BUGS? Scene volume levels randomly change…CPU randomly spikes.

[Nathan Shane]

Hey Fellow Fractals…
FM3 (not TURBO)
FW 8.0
Refresh After New Firmware: DONE
Upgrade All Presets: DONE

BUG1: I’ve recently taken notice of unexpected volume changes when switching between Presets and/or Scenes. I word it that way because I can’t be certain if it’s a Preset issue or a Scene issue. But in regards to Scenes, I’ve noticed that if I save a preset with say, Scene 5 as the default Scene when switching to that preset, the Scene 5 Volume Level has reduced. Switching away to another Scene then back to Scene 5, the Scene Volume is restored. What makes this issue difficult to discern is that it doesn’t occur repeatedly, it’s occurs randomly.

BUG2: Another issue I’ve noticed is that I have a Preset which works as expected but then after switching to another Preset and back again, the original Preset displays CPU LIMIT EXCEEDED! In addition, I can be on a Preset and a given Scene and all is working as expected. Then without changing anything, the Preset suddenly spikes to CPU LIMIT EXCEEDED! I can navigate away to another Preset then back and the Preset is once again working as expected.

NOTE: All these issues occur randomly. There’s no steps to take for repeatability…but these issues have repeated themselves but unexpectedly.

 

[ucnick]

I am running 8.00 final and have done all the refresh/upgrade, yesterday I discovered one of my presets had suddenly begun spiking on CPU usage.
It is a Deluxe Reverb based preset from an Austin Buddy original, I have been using it for the nearly two years now. Two days ago I modified it by adding two additional scenes for a version of Hall & Oates' "I Can't Go For That" which requires a clean snappy tone and a sustained distorted tone. I added the scenes (basically just copied my solo scene and turned on the delay) aznd they sounded good so I saved it.

Yesterday evening I was woodshedding and selected the preset and while on clean (scene 1) it was OK, but as soon as I went to another scene it displayed CPU overload/muting messages. Scratched my head, wtf? Went to another scene, no issue, went back to the DR preset, still overloaded. Rebooted the FM3, still no soap. So shut down and went back to it this morning.
This is right after power up and selecting the preset in scene 1, no overload:


As soon as I went to scene 2 it displayed overload:

Returned to scene 1, now IT shows overload as well:

So I exported the preset to save it and loaded the preset from before I modded it, works fine:

So I modified the older one to include the two new scenes, works fine. ?????!!!!

(390_DLXRVBICGFT)

I've attached the misbehaving preset (390_DLXRVBICGFT.syx) and the new one that works (390_DLXRVB_ICGFT.syx) for comparison for analysis.

 

[unix-guy]

I am running 8.00 final and have done all the refresh/upgrade, yesterday I discovered one of my presets had suddenly begun spiking on CPU usage.
It is a Deluxe Reverb based preset from an Austin Buddy original, I have been using it for the nearly two years now. Two days ago I modified it by adding two additional scenes for a version of Hall & Oates' "I Can't Go For That" which requires a clean snappy tone and a sustained distorted tone. I added the scenes (basically just copied my solo scene and turned on the delay) aznd they sounded good so I saved it.

Yesterday evening I was woodshedding and selected the preset and while on clean (scene 1) it was OK, but as soon as I went to another scene it displayed CPU overload/muting messages. Scratched my head, wtf? Went to another scene, no issue, went back to the DR preset, still overloaded. Rebooted the FM3, still no soap. So shut down and went back to it this morning.
This is right after power up and selecting the preset in scene 1, no overload:
View attachment 140909

As soon as I went to scene 2 it displayed overload:
View attachment 140911
Returned to scene 1, now IT shows overload as well:
View attachment 140913
So I exported the preset to save it and loaded the preset from before I modded it, works fine:
View attachment 140914
So I modified the older one to include the two new scenes, works fine. ?????!!!!
(390_DLXRVBICGFT)View attachment 140915

I've attached the misbehaving preset (390_DLXRVBICGFT.syx) and the new one that works (390_DLXRVB_ICGFT.syx) for comparison for analysis.

Different types of the same block can use different amounts of CPU.

Check which channels of your blocks are used in the high CPU scene.

Also remember that bypassed blocks use the CPU as well, so sometimes you can shave it down by using a different type on blocks that are bypassed in that scene.

This is not a bug - it's how things work.

 

[ucnick]

Different types of the same block can use different amounts of CPU.

Check which channels of your blocks are used in the high CPU scene.

Also remember that bypassed blocks use the CPU as well, so sometimes you can shave it down by using a different type on blocks that are bypassed in that scene.

This is not a bug - it's how things work.

Thanks, understood, I'll check, but the thing is that there are no differences between the original, no-issues preset and the misbehaving preset except for the 2 scenes I had added to the original.

Also scene 1 clean did not initially show high cpu when selected it, when I went to scene 2 it showed high cpu, then when I went back to scene 1 it showed high cpu. That is why I think it may be a bug.

Matter of fact, I had been using the original preset by manually enabling the delay in scene 3 whenever we performed the tune, but I became tired of having to set it up manually every time, so I just created scene 8 as a copy of scene 3 but with the delay enabled. The clean scene in 7 is a copy of the clean scene in 1, no differences, I just copied the scene from 1 to 7, so I had the 2 scenes I need right next to each other. It worked fine for a few days, then it started displaying high cpu...

The new one I created today is, again, a copy of the original, but with the Zen Drive in the drive block, rather than the t808 I used in the solo scene 3 and then 8, I liked the Zen tones better.

 

[unix-guy]

Thanks, understood, I'll check, but the thing is that there are no differences between the original, no-issues preset and the misbehaving preset except for the 2 scenes I had added to the original.

Also scene 1 clean did not initially show high cpu when selected it, when I went to scene 2 it showed high cpu, then when I went back to scene 1 it showed high cpu. That is why I think it may be a bug.

Matter of fact, I had been using the original preset by manually enabling the delay in scene 3 whenever we performed the tune, but I became tired of having to set it up manually every time, so I just created scene 8 as a copy of scene 3 but with the delay enabled. The clean scene in 7 is a copy of the clean scene in 1, no differences, I just copied the scene from 1 to 7, so I had the 2 scenes I need right next to each other. It worked fine for a few days, then it started displaying high cpu...

The new one I created today is, again, a copy of the original, but with the Zen Drive in the drive block, rather than the t808 I used in the solo scene 3 and then 8, I liked the Zen tones better.

Perhaps you have Scene Ignore set on some blocks?

 

[ucnick]

Perhaps you have Scene Ignore set on some blocks?

I have never used scene ignore. So, unless it spontaneously sets itself, I think not.

Again... the misbehaving preset was exactly the same as the working one except for the enabled delay block in the added scene. There were no other variables involved. And it did work fine for a few days.

BTW appreciate the suggestions! I will check...

 

[Joe Rogers]

We will have someone look at these issues.

@Nathan Shane If you would post presets, that would be very helpful.

 

[Admin M@]

@ucnick
I loaded both of your presets and tried switching back and forth between them dozens of times. I never experienced any CPU spikes.
I very carefully compared your two presets attached above and except for the file names and the name of scene 8, I can't spot any differences between them except to note that one of them shows CPU ~70% and the other ~73%. Am I missing something? Can you help identify any differences between 390_DLXRVBICGFT.syx and 390_DLXRVB_ICGFT.syx ?

 

[ucnick]

@ucnick
I loaded both of your presets and tried switching back and forth between them dozens of times. I never experienced any CPU spikes.
I very carefully compared your two presets attached above and except for the file names and the name of scene 8, I can't spot any differences between them except to note that one of them shows CPU ~70% and the other ~73%. Am I missing something? Can you help identify any differences between 390_DLXRVBICGFT.syx and 390_DLXRVB_ICGFT.syx ?II

Interesting. Your cpu loading is notably less than mine.

All are derived from the same preset, DLXRVB (attached). It shows 79.2% usage in scene 1.


DLXRVBICGFT shows 82.9% usage in scene 1.


As soon as I switch to scene 2 in DLXRVBICGFT I see the CPU Limit message.




DLXRVB_ICGFT uses Zen Drive in scene 8 Drive 2, rather than T808. Also looper is bypassed but shouldn't make any difference. I am also seeing 79.2% CPU usage on _ICGFT, same as original. (BTW the scene is misnamed, I forgot to update it and remove the t808 reference).


For grins 'n giggles, I changed DLXRVB_ICGFT scene 8 Drive 2 to t808 to make DLXRVB_ICGFT scene 8 same as DLXRVBICGFT scene 8, usage is still 79.2% and does not spike in other scenes.



I just noticed an interesting action when I load another preset and then load DLXRVBICGFT.
1. Load another preset (e.g. my Cornford preset). It has 64% usage.
2. Load DLXRVBICGFT, scene 1, no cpu spike but it does say 83.0%.
3. Using footswitches I select scene 8 - no cpu spike.
4. Return and select scene 1, no cpu spike.
5. If I select any other scene EXCEPT scene 2 no cpu spike. Scene 3 shown.

6. But if I then select scene 2 - cpu spike occurs.


7. It remains in CPU limit until I switch to another preset and then back to DLXRVB_ICGFT.

Do you want my backup files that I made the day I created the preset? They include the system files as well.

I'm wondering if perhaps I need to reload the FM3 FW, perhaps something has been corrupted somehow, since you are not seeing it.

 

[Joe Rogers]

@ucnick I don't see in any of your posts, are you running an FM3 or FM3 Turbo?

 

[Nathan Shane]

Sorry for my delayed response, I’ve been offline for a few days. User ucnick is reporting the exact same behavior that I originally reported on. The main difference is that there were no specific presets that were consistently problematic. It’s a very random and unexpected behavior which occurs. Despite other FM3 (non-TURBO) users who have not experienced this issue, I am very confident in suggesting that it seems highly probable that the issue only started occurring after installing the most recent fw8.0 available for download. I’ve been using my FM3 just about daily for years and have NEVER experienced this issue with any other firmware release. I will do my best to take notice of which specific preset(s) exhibit this behavior. At least now I’m not the only user experiencing this. LOL.

 

[ucnick]

@ucnick I don't see in any of your posts, are you running an FM3 or FM3 Turbo?

Sorry, been a bit busy, forgot to specify that.

Plain old FM3 purchased in May or June 2022.

Definitely something odd. It stays with that particular preset, no issues with any others so far. I have since replaced it with a virtual twin created from the same predecessor preset and no issues so far.

 

[DJD100]

IME 79% is too close to the limit, try maxing out at 76% or so (I keep mine around 70% with external help)?

 

[Admin M@]

@Nathan Shane Engineering reports that they have found and corrected the first bug you reported, causing levels to vary when scenes are changed. It is related to KILL DRY. The fix will be in the next firmware release.

Your second problem is not a bug. It is due to your preset using excessive CPU and resulting in instability. Here is a summary of our notes on your case:

The preset uses excessive CPU which starts causing the problems observed. Changing presets returns unit to normal operation.
Removing one of the drive blocks or the looper and saving the preset will lower the preset to a stable CPU level and should solve the problem.

 

[Nathan Shane]

@Nathan Shane Engineering reports that they have found and corrected the first bug you reported, causing levels to vary when scenes are changed. It is related to KILL DRY. The fix will be in the next firmware release.

Your second problem is not a bug. It is due to your preset using excessive CPU and resulting in instability. Here is a summary of our notes on your case:

The preset uses excessive CPU which starts causing the problems observed. Changing presets returns unit to normal operation.
Removing one of the drive blocks or the looper and saving the preset will lower the preset to a stable CPU level and should solve the problem.

Glad to hear that Engineering found the issue related to the KILL DRY parameter. Oddly enough, I had actually been experimenting with the KILL DRY in some presets and thinking about it now, it was after that when I noticed the problem first occurring. But it never even occurred to me to be suspect of the DRY KILL. Glad you resolved the issue.