Hey not 1 hiccup running for 5 mins straight! Well done sir.
OLED is indeed still confused. However, it’s not freezing. There’s no i2c sleeping message, and no freeze when blade is off (I have my idle.bmp looping).
Works fine and then screen sleeps as expected.
Just the alignment is wackadoo. (split screen, sometimes 4 way uncentered split.)
Strike that. It seems to be 1/2 screen split duplicate only now. Can’t reproduce quad split oddness.
I’ve seen some weird messages on the digital analyzer that I can’t explain yet, I think once I have those figured out everything will hopefully work fine.
DIsplay code should hopefully work better now.
Confirmed! I can’t believe the speed/rate increase. Amazing, looking great!
How about an audio thing?
Is there a way to always commit preon 1 to out01, 2 to 2 etc…?
It’s possible to add to a prop relatively easily, but it would need some sort of config file to control it on a per-font way.
I should also point out that the preon->out transition is not (currently) gapless.
Similar sort of 1:1 mappings exists in lots of places potentially.
So bgn end files could also be on the table?
Maybe, what is it?
I meant like linking bgnlock1 to play for lock01.
Well, if possible I’d rather make something that works generically for lots of cases than a something that only works for one transition.
Hmm, I might have to do some interesting stuff with the Effect class to support multiple size displays. Right now, it will try to read the same files for 128x32 displays as 128x64 and 64x32 displays. As long as you only have one display, it’s possible to work around this by moving files around, but if you have multiple displays, this becomes impossible.
So, I’m thinking that instead of loading FONT/boot.bmp, I should look for FONT/128x32/boot.bmp.
In theory, this should be simple. In practice it’s going to take some interesting templating to make it work…
The nice thing about this is that fonts can then provide images for multiple sizes if so inclined.
So cool to have multiple OLED’s though! Granted that’s going to be more of a blaster thing. I dont see a lot of sabers with more than one OLED.
Personally I think it would be more fun to have one OLED being able to display a bunch of different information, than have multiple displays that do one thing. Unless the road to option #1 has to go through option #2 first. Then I’m cool with it. 
If that’s the case, would it make sense to not add the size in the path, but in the filename instead, as in boot128x3201.bmp, boot128x3202.bmp…
Just to follow suit of not NEEDING subfolders, but they’re an option?
boot128x3201.bmp wouldn’t work on teensys which are still stuck with 8.3 path names.
Also, I was thinking that we would fall back to read FONT/boot.bmp if FONT/128x32/boot.bmp is not available.
If someone’s going through the process to do OLED stuff, the subfolder is no biggie in my opinion. Sounds like a plan
Sorry, I can’t read the whole post thread, so a quick question here: will ProffieOS 6.x have a boot sound after any button press if board was in Idle Sleep instead of instantly powering the blade on?
No, but Proffie V3 might.
Ok, thanks 
I think this is a great idea and would vastly improve the current button-only (momentary switch) approach to operating everything on a saber.
Cycling through the styles, fonts, and colors is cumbersome with buttons.
Buttons can be relegated to power-on/off and blaster effects, for example. A rotary can simplify all those other operations.