Longer delay to load next/prev preset

What may have changed since OS6 that would cause more delay when switching presets? Is it maybe in something with saving current preset before moving on?
I personally noticed it, but thought it was just me, but now I’ve heard several reports of the same thing. Cycling through presets takes longer to load.
I thought I may have perceived better response after loading a preset once, then the next time would be quicker, but that might be “wishful thinking” on my part.

It’s also noticeable when doing next_preset_fast as there’s a moment of silence and black as it switches.
OS5.9 was more responsive.

It’s most likely due to writing save files. I think it’s fairly inefficient right now. I think every line might cause a write to the SD card.

I’m assuming we’re still talking fractions of sections here, not several seconds or minutes, right?

If that turns out not to be it, then we probably need to sit down and measure where the time is actually spent.

I’d say a good 1-Mississippi in my experience. Occasionally (first time through?) maybe 2-3 seconds.

That seems suspiciously (bad sd?) long, but I suppose if the save files are long, that could happen.

Another thing that is probably adding a little bit of time is scanning the files in the “common” directory.

It might be a little bit of both of them. For my personal experience, I definitely have a common folder.
For the other guy tonight, fresh 6.6 upload but no common folder. He noticed significant lag when doing blaster blocks, so it might be a slow SD in that example. I did not run sdtest on his side. He does have #define SAVE_PRESET. I’ll have him remove that and test if it’s noticeably better.

Or we could just print out millis()in in a few places in the code, do some subtraction and find out how long each piece actually takes.

Well (not me) tested this without #define SAVE_PRESET and said “Yep. It’s faster for sure”
Are these good spots to check times?
prop_base:

    // Go to the next Preset.
  virtual void next_preset() {
#ifdef SAVE_PRESET
    STDOUT << "****** next_preset() called, doing SaveState" << millis() << "\n";
    SaveState(current_preset_.preset_num + 1);
#endif
    STDOUT << "****** SetPreset " << millis() << "\n";
    SetPreset(current_preset_.preset_num + 1, true);
  }

hybrid_font:

void SB_On() override {
    STDOUT << "****** SB_On() " << millis() << "\n";
    // If preon exists, we've already queed up playing the poweron and hum.

then toggle SAVE_PRESET and compare?

There is no need to flip defines.
You just set up a case that’s takes a lot of time, then you add printouts like these ones.
Then you just check the serial monitor and do some subtraction to figure out how long each part takes. You can also add more printouts inside the functions themselves to break down in finder detail what is taking time.

@NoSloppy Thanks for opening the topic. Now I know it’s not just a small section of the user base. I’m definitely interested to see how this plays out and gets solved so I’ll be watching.

im-watching-you-wazowski-always-watching-always

Laying in bed last night it occured to me this all might likely just be due to the fact it’s loading in an additional 143 wav files from the common folder…

*EDIT

…WHICH was mentioned back here already.

I can’t say I’ve noticed any real difference.
I don’t think all of the common sounds are actually scanned, only mnum and clrlst files are set as EFFECT. I believe all of the other sounds are just called directly but maybe profezzorn can confirm.

It reads the common directory, and any subdirectories.
It doesn’t read the files themselves, just the file names.

1 Like