I am just getting started with Proffie. As such I would like to keep styles in the config for now. If I only want to use the settings menu, I should use #define ENABLE_ALL_EDIT_OPTIONS and #define FETT263_EDIT_SETTINGS_MENU and then finally #define KEEP_SAVEFILES_WHEN_PROGRAMMING, right? If I do this only the settings will be pulled in from the ini file on the SD card and everything else will be coming from my config. Is this correct?
I would read this BEFORE using KEEP_SAVEFILES_WHEN_PROGRAMMING as it will still impact updates you may make to the config as all of the .ini files are still updated when Edit Settings is active. In general, this define should only be used if you never intend to change anything via uploading the config going forward. If you use this define then you need to be aware that changes in your config may not be reflected, particularly adding or removing presets, changing the order of presets, fonts, tracks, etc. as well as changes to gestures and certain control features. In general, I do not recommend using this define ever.
1 Like
KEEP_SAVEFILES_WHEN_PROGRAMMING is required to use Edit Mode, though, correct?
No, I tell users NOT to use it. Edit Mode requires
#define ENABLE_ALL_EDIT_OPTIONS
and one of the Menu option defines.
The KEEP_SAVEFILES_WHEN_PROGRAMMING define is only if you only ever plan to do all future editing of the saber via the menu or Workbench.
1 Like
Ok. Then you for clarifying that for me. If one wants to use the menu or workbench to edit, you must use KEEP_SAVEFILES_WHEN_PROGRAMMING then?
Did you read the article I linked above? It explains everything 
If you do not understand the article then you definitely should NOT use that define. You should only use that define if you fully understand what it does and how it works, hence the PSA.
1 Like
Ok. I did read it and I appreciate your help and do not mean to frustrate. Perhaps I should try asking differently or I can seek help elsewhere if you would prefer.
Can you help me understand the expected behavior in this scenario as an example? I want to be able to adjust blade length without reflashing or using BLADE_ID. If I do this using the settings edit menu and KEEP_SAVEFILES_WHEN_PROGRAMMING is not used, the blade length adjustment will not persist and I would have to adjust it with every power cycle. Do I understand it correctly?
This define applies to uploading (programming) the board. If you have this define then all previously saved edits will be used in place of the config you are trying to upload, so if you have any changes in your config that you’re trying to upload they may not appear on the saber. This define has nothing to do with normal editing functions, it only applies to uploading a new config. If you edit your blade length with Edit Mode it will be used until you upload again (or if you delete the .ini files on your SD).
When you upload a new config you are overwriting everything on the saber, so all settings and edits are replaced with the new config.
IF you intend to upload a config but don’t want it to overwrite your previous edits then you would apply this define BUT doing so means that any changes you try to make by uploading a config will be ignored and as the article notes you can get odd behavior or errors if you change the presets or other editable options in the config that were previously changed in Edit Mode. Before using the define you need to familiarize yourself with what it’s doing, which is ignoring anything you tried to change via an upload in lieu of the saved edits. This is opposite normal behavior and often confuses users. It also makes it impossible for anyone to troubleshoot issues as your config is no longer “running things”. For this reason, this define is really only for use by users that fully understand it and essentially only ever intend to make any changes through the menu or Workbench. If you use this define and try to upload any changes via your config they will not appear on your saber along with all of the other noted behavior differences in the article.
If you just want to be able to edit your saber between uploads and/or without needing to upload then you just need to use
#define ENABLE_ALL_EDIT_OPTIONS
This define allows editing between uploads (programming) to be saved to the saber.
Then if you want a menu to make the edits (instead of just using ProffieOS Workbench)
you use one of these defines.
#define FETT263_EDIT_MODE_MENU
or
#define FETT263_EDIT_SETTINGS_MENU
Does that clarify?
I would recommend NOT using the define to 99% of users, if you think you’re the other 1% then go for it but understand what adding it means for your saber’s behavior when you try to upload a change in your config.
1 Like
Kind of wondering when this is ever a thing anyway.
I guess maybe if you wanted to change something that is not saved, like your BladeConfig for some reason?
It’s almost like the define should be called IGNORE_UPLOAD_WHEN_UPLOADING which doesn’t make much sense.
Maybe we should change it so that volume, blade length, and other saber settings are not grouped into the same saves as presets(font, track, blade style ARG and Variation values).
That’s sort of what it is now though, no? presets.ini gets that stuff, and global.ini and curstate.ini get the system stuff?
Maybe it’s just a matter of tweaking KEEP_SAVEFILES to be more like just a KEEP_PRESET_EDITS, therfore allowing uploads to change settings not related to “things i don’t want to lose” like that super customized blade style with unique colors or whatever.
KEEP_SAVEFILES_WHEN_PROGRAMMING predates Edit Mode, it came about with the manual editing of presets.ini in an earlier OS.
The problem with keeping edits after an upload is that users don’t know why their config changes aren’t applying and troubleshooting becomes nearly impossible.
Edit Mode is really intended to make tweaks without needing to upload, it isn’t in place of uploading. To me uploading, and your config should take precedent over “edits”.
I don’t really know if there’s an actual need for new defines as I haven’t heard much feedback to support it, most of the time we get issues when KEEP_SAVEFILES_WHEN_PROGRAMMING is in the config, not when it’s not because the expected behavior is that uploads replace what was previously there.
yes. I think my point was it would be good to have a way to “save the saves” whether that means refining what gets saved/ignored with a define, or making some tool that can merge a presets.ini with the precious edits into a freshly created one.
Something like that.
I agree there’s next to no issue when NOT using KEEP_SAVEFILES, I was addressing moreso the ability to make edits and really keep them between uploads.
Originally save files were ALWAYS kept when programming.
This caused lots of problems, so I added code that ignores the savefiles if they are stale. (from a previous upload)
KEEP_SAVEFILES_WHEN_PROGRAMMING was a safety valve in case my change didn’t work well for some people, but because of cargo culting, it’s spread far and wide for reasons that are beyond mortal understanding.
1 Like
PS: Not sure if this is clear enough. When I say “cargo culting” I mean mimicking without understanding.
1 Like
Really “precious” edits like colors, style options or timings can be made starting points via Style Arguments in the config, that was the driving force behind their addition. They then remain even when you upload and they are the exact same syntax as the presets.ini values so it’s simple to transpose.
Edits to blade length, volume, etc are actually contingent on the new config not having a lower value, so it is a bit of a Pandora’s Box. I personally haven’t seen much need or issues with the status quo, to me it works as expected and intended. We just need to raise awareness not to use KEEP_SAVEFILES_WHEN_PROGRAMMING again. It seems, as profezzorn notes, it’s popping back up from some source that doesn’t understand so best we can do is inform not to use.
1 Like
Meaning copying values by hands from the .ini file into the style ending?
If yes, it sounds like we could use an app to parse that info and append to a given style 
Yup, I have it on a “To Do” list but it’s pretty far down, my config helper has the framework in place so eventually I was hoping to be able to but it’s not something anyone has actually asked about so it’s more of a nice to have.
2 Likes
Thanks everyone. Please check my summary:
Generally speaking, do not use KEEP_SAVEFILES_WHEN_PROGRAMMING. It was intended to address an issue that is no longer really relevant on OS6+.
I believe what really brought this into play for me was the reference here: https://www.fett263.com/proffieOS6-edit-mode.html
Where it says
It is also strongly recommended you include:
#define KEEP_SAVEFILES_WHEN_PROGRAMMING
before referring to a detail page about it.
(@profezzorn Thank you for adding “cargo culting” to my knowledge base as well.)
I have removed, the original assumption was users would read NOTE and understand the linked document, but you know what they say about “assume-ing”. Easier to just have the define disappear from the community and then if someone displays a real need for it in the future, direct them to the information.
1 Like
For anyone searching this topic here’s a quick config top-section example for running Edit Settings rather than the full Edit Mode. **You should STILL read the information in the links that Fett263 provides. It’s all there.
//1 blade 2 button example.
#ifdef CONFIG_TOP
#include "proffieboard_v2_config.h"
#define NUM_BLADES 1
#define NUM_BUTTONS 2
const unsigned int maxLedsPerStrip = 144;
#define EXTRA_COLOR_BUFFER_SPACE 60
#define VOLUME 1500
#define CLASH_THRESHOLD_G 4
#define AUDIO_CLASH_SUPPRESSION_LEVEL 5
#define ENABLE_AUDIO
#define ENABLE_MOTION
#define ENABLE_WS2811
#define ENABLE_SD
#define KILL_OLD_PLAYERS //Note: KILL_OLD_PLAYERS is scheduled to become standard OS soon.
#define MOTION_TIMEOUT 60 * 5 * 1000
#define IDLE_OFF_TIME 60 * 5 * 1000
#define DISABLE_BASIC_PARSER_STYLES
#define DISABLE_DIAGNOSTIC_COMMANDS
#define SHARED_POWER_PINS
#define ENABLE_ALL_EDIT_OPTIONS
#define SAVE_STATE
#define NO_REPEAT_RANDOM
#define COLOR_CHANGE_DIRECT
#define FETT263_EDIT_SETTINGS_MENU
#define FETT263_SPECIAL_ABILITIES
#define FETT263_SAY_BATTERY_PERCENT
#define FETT263_DISABLE_CHANGE_FONT
#define FETT263_DISABLE_COPY_PRESET
#define FETT263_BATTLE_MODE_ALWAYS_ON
#define FETT263_LOCKUP_DELAY 200
#define FETT263_BM_CLASH_DETECT 6
#define FETT263_SWING_ON_SPEED 250
#define FETT263_SWING_ON
#define FETT263_TWIST_OFF
#endif
#ifdef CONFIG_PROP
#include "../props/saber_fett263_buttons.h"
#endif
Side note, @Fett263 the kids (and now me) love the EditSettings option. Thanks man!
1 Like
re: cargo-culting
IMHO It’s because some vendors the past few years still put it in their configs like it’s even a valid thing anymore. Then when we tell users different and they ask the vendors/companies they (the vendors) don’t bother to ask one of you to validate. *Yep, beyond mortal understanding. AFAIK nobody uses this much anymore.
1 Like