We could make it backwards compatible though, so that if BootImageDuration is not specified, but FontImageDuration is, it would use that.
I kind of think I should fix that so that old configurations work as they used to.
1 Like
As someone who has been loudly critical of companies like Apple for actively breaking functions that are more than five minutes old, I love your commitment to backwards compatability Prof! So refreshing in this day and age and is just another thing that makes ProffieOS the best thing ever in the entire world of computing! 
Just a quick update - the ProffieOSBootImageDuration thing has indeed resolved my issue: runs perfectly with the sub-config in the oled folder and the SD card file structure as per my main config. Makes things nice and neat.
And on a brief aside, a couple of weeks ago, I altered my SD file structure so that no more than 15 folders sit inside another folder, as per the Prof’s comments on another thread about speeding things up in terms of wav file access. (Hence the FontPrem/Graflex and Shared/Function/oled address lines. I even left the ‘s’ off the end of Functions to keep the filename below eight characters 
I hope you’ll forgive the SD screenshot on this one occasion Prof. 
).
This has definitely made a difference to system speed and has all but eliminated what were admittedly only subtle and occasional clicks on the audio. Definitely worth doing, and I’m loving my new, super-tidy and streamlined SD card layouts. 
Sincere thanks as always guys.
1 Like
shoot, I thought we addressed this.
I guess the misstep was assuming a default boot Image duration would cover the case of no Font duration specified, wheras backwards compatible would more mean filling the expectation of Boot image being tied to the font image timing.
Can’t wait for the wiki instructions, Epic!
Not sure what you’re waiting for.
All OS7 features have already been documented
Links to the documentation for each new feature can be found here
1 Like
Just in case anybody wonders why I’m not testing stuff on the list above: It’s because I’m busy updating the style editor for 7.x
3 Likes
Ok, we have our first 7.0 bugfix: I made boot image time fallback on fontimageduration to make it more backwards compatible.
I’m going to wait a day and see if any other issues are found before I make a 7.1 zip file.
1 Like
This is very much appreciated
1 Like
I created a 7.1 zip file.
Same as 7.0, plus:
- OLED boot images have a backwards-compatible duration
- A button fix in the Fett263 prop
So did you confirm that syncing the image duration with the wav file works for you? (setting image duration to Zero in config.ini)
Someone other than me should chime in that that feature is tested 
New OLED images test (note- lock already existed, doesn’t need to be on this list)
3 Likes
I’m out of sabers to do the tests. I’m in the process of installing one. But it will take about four days if the chassis prints right. After that I will keep it mostly as a test saber, though.
I want to install Oleds and a few of my sabers. I cant wait…
Not yet, but I’m installing two hilts with OLEDs in the next day or two, so will give it a go then. All I’ve really done so far is set the frame rate and overall duration of the boot file manually as it were. However I’d like to try it on clash and blast effects so the picture disturbance follows the audio.
One question on that though - how does it achieve it? If you have a bitmap of 100 frames and a frame rate of 25 frames per second, the picture can follow a two second wav file in one of two ways - it can either speed up the frame rate to play all the frames in two seconds rather than four, or it can play 50 frames of the animation and then cut away before it reaches the end.
Just wondering which one ProffieOS will do. I’m guessing, based on my earlier boot file observations before the Prof fixed the backwards compatibility thing, that it’s the latter. Am I right?
If I remember correctly the duration is ignored for non-looping animations. For non-looping animations, it just plays until the animation is finished.
For looping animations, and for single images, the duration is applied. (Without changing the frame rate.)
1 Like
Brian, I just figured out a way of testing it and yes, for my purposes, setting clash and blast durations to zero does work and plays the bitmap at the specified frame rate for the duration of the wav file, then cuts away from the bitmap if it hasn’t completed.
Prof, I assume things like clash and blast count as looping animations, in that if the wav file is longer or the specified bitmap play duration is longer than the bitmap itslef, then it will keep looping until the wav or duration code tells it to stop?
If so, it’s working perfectly.
Correct. A looping animation plays at the standard set frame rate for whatever duration of the wav, truncated if the sound ends early, and looping if the sound length exceeds the image loop.
Non looping images, which you likely don’t have any of, are one shot playback that play through once, ignoring any duration settings…I think.
You can test with this non-looping file:
1 Like
The Effect_On feature is that for your new power on for OS7?
EFFECT_ON and EFFECT_FAST_ON are for use in Interactive Preon or Ignition effects (or chained and conditional effects) where the blade is ignited by an action other than the standard control via my prop.
1 Like