That makes no sense. The font2 preset would only look additionally in ‘comun’.
Something else must have been awry. Like KEEP_SAVE_FILES_WHEN_PROGRAMMING was active or something like that.
1 Like
This won’t work because Edit Font and Change Font will overwrite if you change the font. When you use Edit Font it makes that presets font “font;common” so you “comun” folder would disappear.
The voice prompts in the font t should work fine.
1 Like
Ah, understood. IOW it always writes a default Font Search Path with the syntax being the new selected font appended by exactly ;common
so any existing custom path(s) would be overwritten when the edit is saved.
Good to know.
1 Like
yeah I spent far too much time trying to make a script to run and remove the common files from the root font folder but I ended up doing it manually (which also took forever). BUT it’s now done, I will see if I can reproduce the issue I had,
using my 5.9 config (INCENDIUS2.H) and then using the test file from Fett263 (test.h)
P.S. I’M getting an error it sounds like “error in font directory” so I’m going have to check the font folders.
You could have just tested by removing the files from one font, this way if that’s not the issue you wouldn’t have wasted that much time 
I don’t see how having menu sounds in font and common would react any differently than normal font search path but let us know.
Run the “effects” command, it will tell you which group of files has a problem.
Update / Explanation for On-The-Fly Color Change (currently on github)
There are several methods for Color Change “on-the-fly” with ProffieOS6 and my prop file depending on the style your preset uses.
My prop will select the correct method based on the current preset.
#1 ColorChange styles:
For styles that use ColorChange built in the on-the-fly color change will rotate through the colors listed within the style -or- if you use the COLOR_CHANGE_DIRECT define then each click for ColorChange will change to the next color
#2 ColorWheel:
For styles that contain RotateColorsX or no Color Change or Color Editing the ColorWheel will be used for on-the-fly color change. This will allow for any color to be selected and will change the RotaeColorsX or any color (except White or Black) on all blades.
New for OS6 Color Zoom - during ColorWheel you can hold down the PWR button as you turn to Zoom into a specific color and release the button to save. Color Zoom makes it so a much larger turn is needed to change the color making it easier to select specific colors.
#3 Color List:
For OS6 Edit Mode Styles that contain Color Editing the on-the-fly color change will use the Color List functionality. This is applied only to the Base Color for all blades (all other effect colors would need be changed via the Edit Mode Menu or ProffieOS Workbench - refer to Edit Mode information).
The Color List is 27 specific colors that can be rotated through.
You can adjust any color from the list using Color Zoom (meaning you can get to any color you want) by holding the PWR button while turning then release the button when you get to the exact color you want to Save. Color Zoom makes it so a much larger turn is needed to change the color making it easier to select specific colors.
Note: you can have the actual colors in the Color List spoken if you include the Edit Mode voice prompts and use FETT263_SAY_COLOR_LIST_CC define. This will speak the colors as they are selected (does not apply to Color Zoom).
3 Likes
I have noticed some delay in thrust functionality. Im having to wait 7 seconds from boot and in for it to function. This is happening on both of my test sabers. 1 running proffie 1.5, the other one proffie 3.7. Just curious if anyone else is seeing issues with thrust ignition? Swing and twist work without waiting.
Tom
1 Like
There’s no delay on the thrust for me and nothing in the code (it’s unchanged since OS5). I did notice on your live show you seem to do a very short stroke when trying to ignite. Maybe try lengthening the linear movement you’re doing. The movement needs to continue long enough to be detected, very short movements wouldn’t trigger.
2 Likes
test the sd card I found cheap sd cards cause delays in the files.
22sas on 3.7, 12 sas on 1.5. Not the sd. Huge difference in thrust between 5.9 and 6.xx
Something is different.
1 Like
Maybe a video? I tested and works normally for me. No changes were made in my prop for Thrust.
2 Likes
I let the saber sit on my desk and then I tried to turn it on and the hum didn’t work.
My question is if I don’t have a kill switch and don’t pull out my battery would I fry something? (P.s. I haven’t done this, just want to confirm first)
What do you mean? No kill key and battery left in means the board is sitting idle and powered…which of course is normal and fine.
Will try tonight, 5.9 vs. 6.xx thrust. Gotta take kid to game first.
sorry dude, I meant if i plug the usb in.
I think I understand. Plugging in USB with or without battery or killswitch is fine.
Connecting or removing battery power while USB connected is fine.
SD card is really the only volatile element in the mix, where inserting or removing it while the board has power (from battery or USB) is a bad idea, as well as unplugging the USB connection when Mass Storage is active, and the card is disconnected from the computer without gracefully ejecting it.
1 Like
so, just making sure that I can plug in the usb WITH the battery connected AND ensure that the sdcard is plugged in. (Serial + Webusb) should be ok on my LGT saber.
So my os6 preset file is test.h and I was able to reproduce the no hum issue. the hum while off issue was only presented once but I had checked the files in all the fonts and fixed them to only use the common folder for the edit mode.
17:38:05.072 -> channels: 1 rate: 44100 bits: 16
17:38:05.139 -> Battery voltage: 3.91
17:38:06.301 -> Playing Bank13/swingl/swingl01.wav
17:38:06.301 -> channels: 1 rate: 44100 bits: 16
17:38:06.434 -> Playing Bank13/hum01.wav
17:38:06.434 -> channels: 1 rate: 44100 bits: 16
17:38:11.147 -> I2CBUS: last_request = 346073 (now = 346074) i2c_detected_ = 1 used = 1
17:38:11.147 -> I2C STATE: 3
17:38:11.147 -> current: 0 id= 0 next= 0
17:38:11.147 -> last: 0 id= 0 next= 0
17:38:11.147 -> Motion requested: 1 (millis() - last_motion_request=15470)
17:38:13.570 -> Playing Bank13/swingh/swingh01.wav
17:38:13.570 -> channels: 1 rate: 44100 bits: 16
17:38:15.063 -> Playing Bank13/swingl/swingl01.wav
17:38:15.063 -> channels: 1 rate: 44100 bits: 16
17:38:17.187 -> Playing Bank13/hum01.wav
17:38:17.187 -> channels: 1 rate: 44100 bits: 16
17:38:22.067 -> Playing Bank13/swingh/swingh01.wav
17:38:22.067 -> channels: 1 rate: 44100 bits: 16
17:38:23.825 -> Playing Bank13/swingl/swingl01.wav
17:38:23.825 -> channels: 1 rate: 44100 bits: 16
17:38:25.152 -> Battery voltage: 3.91
17:38:27.939 -> Playing Bank13/hum01.wav
17:38:27.939 -> channels: 1 rate: 44100 bits: 16
17:38:30.594 -> Playing Bank13/swingh/swingh01.wav
17:38:30.594 -> channels: 1 rate: 44100 bits: 16
17:38:32.552 -> Playing Bank13/swingl/swingl01.wav
17:38:32.552 -> channels: 1 rate: 44100 bits: 16
hum during the off is going on with the test file.
test.h (95.2 KB)
Can confirm. I have an LGT as well. I’ve used Web USB and even uploaded a config with the SD and battery still in with no issues.
1 Like
thanks man.