NOTE: If you’re uploading new configs then you’d need to use this define or the volume would still reset to max when you upload the new config.
HOWEVER, this define will also hold onto all previous edits so if you change fonts or styles or add or remove presets in an upload they will not show on your saber so definitely read through this before using.
The SAVE_STATE and SAVE_VOLUME are for saving between boots, not uploads. Typically when you upload a new config it assumes that’s how you want the saber to be, the KEEP_SAVEFILES_WHEN_PROGRAMMING will apply all save files over the new config but that can cause issues if you’re making changes or adding/deleting presets or features as the old config settings will still show. So you’ll want to be mindful of everything listed in the above article if you use, some users are confused by this when using the KEEP define.
# Set the volume for each effect individually, in percent.
# 50 makes it half as loud. 200 makes it twice as loud.
# Maximum allowed value is currently 255. The default is 100.
# EFFECTNAME can be "clash", “preon”, “out”, “pstoff”, etc.
Maybe you’re thinking I just want to change the volume of the boot.wav file for the sound font? I don’t need to adjust volumes per effect. I’m talking about the overall volume of the saber after I’ve uploaded a new config to the board and I power the saber back on.
I want the saber to power on at 50% volume after an upload, but I still want the option of dialing the volume up to 100% using the volume menu. Currently, after you upload, you get booted back up to 100% volume. I can set VOLUME to a lower number, and it will boot quieter, but then I can’t crank it up later if I want to since VOLUME dictates the maximum volume.
SAVE_VOLUME doesn’t solve this problem, but it at least perseveres my volume setting between toggles of the kill switch. I can deal with the volume reset after a config upload.
I think we just need to break out defines to allow users to “KEEP” certain .ini files on programming, specifically global.ini ,curstate.ini and gestures.ini
This way if users edit volume, blade length, clash threshold and/or gestures they can keep those changes while still updating the presets in their config. I find most uploads after editing would be adding or changing styles in the config for their presets so giving defines like:
KEEP_GLOBAL_SETTINGS_WHEN_PROGRAMMING //keeps global.ini
KEEP_CURRENT_STATE_WHEN_PROGRAMMING //keeps curstate.ini
KEEP_CONTROL_SETTINGS_WHEN_PROGRAMMING //keeps gestures.ini (in my prop)
would be simpler and better approach. I find once a user sets these value they aren’t usually trying to change on future uploads.
If you agree I can add it to my OS7 list unless you have a specific way you’d want it.
Thanks a ton! I haven’t tested this code yet, but I definitely will when I get some free time. I’m a software engineer, but I just haven’t taken the time to really look into how ProffieOS works and how to code for it. Adding this boot volume thing might be what I need to get going.
I cannot figure out where to put this. I made a copy of saber_fett263_buttons.h and tried adding it in multiple places. Is that how I should be adding this in? I keep getting this error:
error: 'dynamic_mixer' does not name a type
I’m not really familiar with this language (some flavor of C? Setting the language mode in VS Code to Objective C seems to work best). If you have any tips or resources to link me that might help me learn how to code specifically for ProffieOS, I’d appreciate it.
Making the edit to dynamic_mixer.h worked. But that change only ensures my volume is set to BOOT_VOLUME after an upload. It did not use BOOT_VOLUME when toggling the kill switch. This is because Edit Mode enables SAVE_VOLUME. So in ProffieOS.ino, I just commented out #define SAVE_VOLUME within the #ifdef ENABLE_ALL_EDIT_OPTIONS block. Now I can upload or toggle the kill switch and when the saber boots up it will always start at BOOT_VOLUME.
Hopefully there are no negative side effects in making those changes. I was really hoping to get this done without editing the “core” ProffieOS files so I wouldn’t have to put all my custom stuff back in when future OS updates arrived. For now, though, this is fine.