Configure boot volume vs max volume?

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.

Thanks for that info! I could see how enabling that might lead to some undesired behavior. It seems a little overkill for what I want.

Having another define for boot volume would be a welcome addition to a future version of the OS :wink:

# 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.
# ProffieOS.SFX.EFFECTNAME.volume=100

Sound font config.ini file :wink:

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.

Something for ProffieOS 7.x maybe?

1 Like

How about if you add #define BOOT_HALF_VOLUME to your config, then add to your prop file something like

  dynamic_mixer.set_volume(std::max<int>(VOLUME * 0.1,
  dynamic_mixer.get_volume() - VOLUME * 0.50));

Or you could make it a settable percentage right in the define.

#define BOOT_VOLUME .30

then in the prop

  dynamic_mixer.set_volume(std::max<int>(VOLUME * 0.1,
  dynamic_mixer.get_volume() - VOLUME * BOOT_VOLUME));

Someone should check my code there. I’m not sure if float is an issue.

I have no idea why the formatting looks different on here between those 2 practically identical code blocks

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_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.

1 Like

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.

1 Like

Seems easier to have the boot volume in the same unit as the volume.



If this would be useful, I don’t mind having the extra defines for it.
A PR would be most welcome.

Sounds good.

100%. That is really easy.

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.

Line 3731 uses it.
No reason you shouldn’t be able to stick that BOOT_VOLUME part in there maybe at 3720?

The language is C++.

Actually, probably the right implementation is to change this line:


 int32_t volume_ = BOOT_VOLUME;

Although the #ifdef might be better to put somewhere else, like after the CONFIG_TOP include in ProffieOS.ino, that way BOOT_VOLUME could be used anywhere in the code.

1 Like

This would mean that dynamic_mixer.set_volume(BOOT_VOLUME); would need to be in the prop somewhere to actually set it, right?

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.

Thanks for all the help along the way.

Or could/should this go right in prop_base.h then?

I tried to find a good place for it, but ultimately I think just making the change in dynamic_mixer.h is better.

ha. Always go with your first guess.
Tested and works like a charm.

Want a PR, or is this something you plan to add yourself since it’s so small?
Where would documentation for a new valid define feature go?
In the official OS7.x release thread when it’s made?

Yeah, I usually read through all the commits when creating the new release thread, and then I try to update the CONFIG_TOP wiki page from that.