I just used the SDCard Formatter tool and replaced the common directory with the one NoSloppy removed the metadata from. That fixed the issue.
I’m going to recompile with the updated plug-in as well. But I figured it would be an interesting data point.
So, the old method of beginning every blade style with { “SmthJedi”, etc… does not apply with the new blade styles?
The preset begins the same way. The new element is adding another font folder to the font search path, and it’s called ‘common’.
There will be more documentation coming, but the short story is:
A font folder named ‘common’ came to town.
It wanted to offer its possessions, which were a bunch of sound files of spoken voice prompts and menu sounds. It said “Hello! I am here to offer myself for the inclusion in the Operating System. I can help keep users on track whilst editing their saber options by providing aural feedback and clarity as to which menu thou art in.”
The Proffie Gods looked upon him, and saw that it was good.
So common was given a place in the preset.
Immediately following the main font, separated by a semicolon, thusly:
{ "Font;common", ..........
The OS will search the folders in order, so anything not found in the main font (spoken menu items, sounds…anything the OS uses actually) will next be searched for in the next folder in line…the 'common; folder.
It is not mandatory by any means to include the common folder in your font search path, and presets without it will work just fine, provided those sounds aren’t needed Hence why it is a requirement for using Edit Mode.
It’s also very helpful to house “backup” sounds that a given font may not include, such as stabs, or lb.wavs. A copy of your favorite config.ini and smoothsw.ini files can also go in there in case the font doesn’t have those. OLED images are also universally available using this method.
ANYTHING not found in Font, gets searched for in common.
The End.
Not if you’re using my prop in OS6.
Definitely read through all of the documentation provided here before using OS6.
At a minimum you’ll need the Voice Prompt sounds linked in first post to be in “common” folder and to have all of your presets set up as “font;common”. This is to provide a fallback for menu prompts that are used throughout my prop. Without these sounds you may get lost in the new controls as they expect these sounds to exist.
You can also put different Voice files in each font if you want but the “common” folder still needs to exist and contain these sounds.
Sooo, long story short: replace the word “font” with the name of your actual font, using the new format, and then that line of code goes at the start of every blade style?
And then on the SD card, make sure that you have the “common” folder full of the previously downloaded voice files on the root and a “tracks” folder with your font specific music inside of every font folder? Am I tracking correctly?
I did all of the above and it seems to be working properly. 
I’ll get into testing probably tonight after work.
Pretty much, as long as you mean “preset”. The syntax for your presets in your config is the same, we’re just adding the common folder as a font search path now.
The syntax for every preset in your config is:
{ "font;common", "font/tracks/track.wav",
StylePtr<...>()
},
Your “tracks” folder can be in either the font folder or common folder or both for Track Player. The tracks in the font are specific to the font, the tracks in common will be used in all presets and you can mix and match if you have tracks you want to use universally just put in “common/tracks”
PLEASE add labels to the end of your presets.
It gives better error messages, improves webusb interface, and is helpful if you’re using the serial monitor and/or OLED displays.
{ "font;common", "font/tracks/track.wav",
StylePtr<...>(),
"label",
},
It’s not required, but it’s all around a good idea.
I have added a new “Motion Wake” control to my prop that was just merged (get latest version from github by clicking green “Code” button and select “Download ZIP”) if we can get some users testing it out.
To enable use this define:
#define FETT263_MOTION_WAKE_POWER_BUTTON
This will change the Power Button short click behavior on both 1 button and 2 button when the motion times out (per MOTION_TIMEOUT define - default is 15 minutes).
When enabled you will do a short click on PWR to “wake up” motion on the saber but it will not ignite, instead the boot sound will play to signify the motion is active again. This will allow you to turn on your gesture capabilities without igniting. Then to ignite with a short click you would click again once motion wakes.
Note for combos of PWR and Twist or PWR and Swing while off you will need to first click PWR to wake the motion, then do the combo control otherwise the Twist/Swing will not be detected.
For 2 button sabers, any AUX button presses will still wake up motion but also still do the respective action. This define only applied to the short click on PWR button IF the motion has timed out.
cool. I COULD really use this,
This is absolutely amazing, thanks so much for adding!
It’s working perfectly on both one and two button so far, and pretty much exactly what I was expecting 
I had a couple questions/suggestions, I didn’t know if any of this would be doable or a lot of work, if not I’ll try to mess with it myself, I still have to dive into prop editing lol
Is it possible for this to be silent or to play something other than the boot.wav that can be removed? Personally I’d like it to be silent (I removed gestures off and on too), but obviously that’s personal preference
I’ll preface this next part by saying that currently a quick double click works perfectly on two button to wake/ignite the saber (and a kinda delayed double click on one button to avoid activating track player), so if the boot sound was removed then personally I think it works great as is, but I also considered this:
I know control options are running short, but is there any way to change the control for two button so a short click can still power the saber on, maybe like a double click and hold will wake it or something? One thing I’ve always loved about proffie two button is the instant power on and off from a single click on the power button instead of needing to wake the saber or hold anything (and I know the double click and hold control is already taken up by the “activate muted” on one button). I don’t know if this means the short click to activate would have a short delay after the motion timeout or if it would interfere with the double click to activate muted, but my thinking is for people using this define there’s already that “delay” of needing to click twice to activate with the button after the motion timeout. And maybe it also works more in conjunction with the motion controls for people like me that like to flit back and forth between motion and button XD
Lastly, would it be possible for the wake up to also toggle gestures on if gestures off was activated before the timeout? Otherwise it’s “wake up” then “gestures on” then whatever gesture to power on if gestures off was activated
My thinking for all this is the motion timeout can be anything like 5-60 minutes for people wishing to save power on the gyro, but if you’re at a con or doing a choreography or something the gestures off is perfect for putting it on your belt. Then depending on your setup and how much time has passed it would either be “gestures on” then ignite, wake and ignite, or a standard single button press or gesture to ignite (assuming this new define is enabled).
Again these are all just my thoughts based on how I’ll use it/how I think it’ll be used, it currently works great and if these things can’t be done then like I said I need to learn how to mess with my prop file anyway Thanks again!
If it’s silent, how do you know if it worked or did anything?
Short answer is anything is possible but this seems like something you’d probably want to do on your personal saber and less like something that would be beneficial to the wider audience.
Having the saber not play a sound when it’s coming out of a Motion Timeout seems like it’ll cause more confusion to the general users and thereby create more questions or people thinking their saber is broken.
Gesture Sleep is completely separate from Motion Timeout so it’s not a small change to do this, again possible but seems like a specific use for your taste.
At this time, I’d say once the OS is finalized you can make these changes to your personal version. Longer term, if there are things to change up etc, we always have OS7 
Well for this particular function if I’m double clicking to turn on or clicking then immediately performing a gesture then I imagine I’d be doing it too fast for a voice prompt to make a difference anyway. So either it turns on while saying “son of darkness” for example, or if it didn’t work then there’s no voice prompt but it doesn’t turn on anyway. But I know some people like the prompts which is why I suggested something different that could more easily be removed than boot. Otherwise I feel like at that point it’s very similar to just using a kill switch lol. But again that’s just my thinking based on how I’m using it/how I think it could potentially be used for people that use this define
Edit: and there’s also the appeal of waking the saber then igniting via gesture later before it goes to sleep again
Sounds good, sounds like it’s time to learn how to edit my prop file lol
All 3 hilts are loaded with 6.1 no major issues showing so far. 
Updating the EnglishC folder and mhum solved the other stuff.
I got all my software fully updated, running the current version as of 12-24, and everything is working great.
Feature Suggestion:
It would be great if we could define both a maximum volume and a starting volume in our config, as well as a starting brightness.
I know both settings will save, but when uploading a new config and turning on for testing, it would be wonderful to be able to keep things quiet and subtle. Rather than having to edit the volume and brightness each time.
I know I can keep savefiles when programming, but that can cause problems when adding or adjusting styles.
If something like this already exists, my apologies for not seeing it.
Thanks!
I think I figured out why saving would crash if your SD card was unavailable. I checked in a fix on github, which will of course eventually become part of ProffieOS v6.2.
Volume and Brightness (dimming) are saved separately from the presets (in global.ini) so use:
#define KEEP_SAVEFILES_WHEN_PROGRAMMING
and delete the presets.ini and presets.tmp files on your SD card when you upload a new config. This will let all your preset changes show while keeping the last volume and dimming values you saved. You can also delete the curstate and gesture files if you want to reset blade length and/or gesture options to match the new config or keep to use last saved values for both.
There will be a more detailed write up on editing and updating the .ini files once I finish the OS6 library and have time to sit down and write it but for your purposes just keep the global.ini with the starting values you want and it will accomplish.
Confirmed here, working well.