OLED Newbie Questions

I’m new to the OLED party, but I’ve been experimenting over the last couple of days.
I’ve got it working thanks to NoSloppy’s excellent video tutorial series, but I have a few little questions:

I’ve noticed that regardless of the length of a boot animation, it seems to play around five times. Is this controllable in the config somewhere? I know you can use the bpm thing to stop animations looping, but the way I’ve built my animations doesn’t yet include the slices that Brian talks about to split out the frames. All I did was grab a CFX animation as a single bitmap and add my own layers on top of each frame in Affinity Photo (Photoshop equivalent). I guess I will need to get to grips with the slicer thing in GIMP. WIP. :slight_smile:

Kind of related to the above, is there anywhere I can specify how long the OLED should display a given single frame or animation? I seem to recall reading something about editing the font’s individual config file, but all the ones I’ve looked at just have a humstart number and nothing else.

I’m guessing that since the files are dealt with the same as wavs, that you can’t stack them so more than one file plays in sequence? The reason I ask is making long clip files that are 128 pixels by about 10,000 pixels could become a little unwieldy in the picture editing software if you want “edits”, although I guess it would word and might well be easier than any alternative.

The book says to wire it to the SD + and regular ground. Does this mean it will never power down until you use the kill key? If so, is there any harm in running the negative from an LED FET and using a bladestyle to power it down after, say, 15 minutes of inactivity?

As always, any thoughts welcome.
Thanks in advance.

I have a lot of updates pending to the display file, including support for addtional images, auto-syncing to wav length, etc… But in its current form:

  1. The boot animation uses the font image timing, and you can adjust it in the font config.ini.
# Font image duration
# Default 5000.0
ProffieOSFontImageDuration=5000.0
  1. If your font config.ini has nothing but humStart, then any of these additional parameters can be added for more control:
    ProffieOS Documentation: Sound Font config.ini configuration
    including:
# This specifies the frame rate of animtions.
# If not specified (or set to zero) the frame rate will be 24 frames
# per second for non-looped animations. For looped animations, the
# frame rate will be set so that the loop takes one second.
ProffieOSAnimationFrameRate=0.0
  1. Without additional coding, yes, the files currently play the same as wavs and don’t auto-follow in any way.
    You’d just need to add additional frames onto a file to create a sequence like you’re saying. This is pretty easy via imagemagick command line tools, as you’d just add your second (and third and fourth etc…) image frames to the pile to be “appended” together.
    Example . image 1 = frames 1-20. image 2 = frames 21-33
    Name all the frame image file sequentially from font001 through font033 and then run convert .
    I have font.pbm that is 128 × 5632 and plays no problem.

  2. There’s a few posts around here talking about OLED power. There’s nothing currently in place to make it “really” sleep. I think it just shows black. OLEDs don’t draw much power (~20mA), and putting the negative on a FET it can still leech power from a data line i think, but @profezzorn can provide more detail.

The problem is that there is no wakeup code currently.
If you cut power to the OLED, it won’t work anymore until re-initialized.
It shouldn’t be all that hard to add, I just haven’t gotten around do it.

1 Like

Thanks so much for this guys - always appreciated and I’m now well on the way to making my first OLED work the way I want it to. :slight_smile:

I’ve made a small feature request for 7.x for the parameters to be adjustable globally in the main config, rather than having to make changes per font, or in hybrid_fonts.h. But that’s only a minor thing - the current OLED toolbox is amazing! Thanks again.
:slight_smile:

Font Search Path works for config.ini files as well as sounds.
So if you put your global parameters in a config.ini file in a common folder, they will be used if no config.ini is in the font itself, and will be ignored/overridden by having a config.ini upstream in the font as usual, so it can be either; per-font based or global.

That said, I suppose it wouldn’t be impossible to have a dedicated config file for the screen in the future. Some code that includes stuff like:

FontOledConfigFile font_oled_config;.

and then do

font_oled_config.ReadInCurrentDir("oledconfig.ini");

to get the parameters? (or maybe “screenconfig” is a better nomenclature?)

That would break the all-or-nothing use of the font config.ini for both audio and display settings, and then the OLED settings could be global while allowing the audio to still be set on a per-font basis.

Yeh I did wonder if config.ini could be at the end of a search path. But I also thought as you do that it might not be the best idea as I know the ‘proper’ fontmakers do tend to tweak some of those audio settings per font. So yes, divorcing video from audio would be useful on that score. But as I say, it’s no biggie. :slight_smile:

I guess I’m in a wish-fulfilling mood today.

I made it so that it will scan the font search path backwards and read config.ini in every directory in the search path. So if your font search path is "font;common" it will read common/config.ini then font/config.ini and any variables specified in font/config.ini will override any variables specified in common/config.ini.

(On github master, not tested…)

2 Likes

Oh wow! :open_mouth: That’s amazing! :smiley: Thanks Prof! :+1:
The saber I’m building will be finished in a day or two, so I’ll report back on how it works!
:slight_smile:

Sorry. Only one coffee so far so I’m likely missing something here, but how is going backwards better?
I guess this way you don’t need to delete anything from a provided font config.ini for a global default to be used.
Yeah, I think that’s it.
And that is cool!

You have it backwards I think.
Config files in font directories are “more specific” than the ones in the common directory, and thus should have precedence. Values specified in the common directory will be overridden by values specified by config files in the config directory, not the other way around.

By reading the files in backwards order, the reading code can just overwrite anything that was already set.

If you want to override some config values for all presets, regardless of what the font config file says, you can do so by adding another directory to your font path, like:

   { "global;font;common", "tracks/barbapappa.wav",

In this case values in global/common.ini will override everything else.

1 Like

Not to drag this out, but isn’t the end result the same then?

If searching forward in font path (the way it was):
“font;common”
Font config sets humStart.
Common config also sets humStart, but is ignored.
Font config value is used.
In order to use common, either font config value needs to be deleted or by adding another directory beginning of the font path and use that instead of common.

Backward:
Common config sets humStart.
Font config also sets humStart and overwrites previous value.
Font config value is used.
In order to use common, either font config value needs to be deleted or by adding another directory beginning of the font path and use that instead of common.

Before it would stop as soon as it found a config file, so if there was one in both “font” and in “common”, then the one in common would never be read at all.

ah. so it WAS whole file based before and not per-variable based. Is that right?
So it’s 2 changes actually; now per-variable, and reverse direction search.
Am I finally correct?

So regardless of how it actually achieves it, the bottom line is that whatever is in the individual font folder will always take precedence over anything in the common folder. In the case of a wav file it’s the whole file, in the case of a config.ini file, it’s individual parameters specified in that file. But the over-riding principle is that if the font folder expresses an opinion on anything, it will always have the final say.

I love it! :smiley:

Well it’s a major improvement if it’s individual variable-based. (or just ingestion on my part if it’s been that way the whole time)
Maybe it’s been that way the whole time and I assumed otherwise, but that makes it really easy to just have just all the OLED parameters in a common config.ini and not worry about needing to set any audio stuff in the same file, as they’ll be provided in the font’s config.ini.
Super cool.

1 Like

Indeed you are. :slight_smile:

2 Likes

One little thing has just occurred:
before, the board would stop reading files as soon as it found one on the search path. But now the board has to read all files then select the highest priority aspects of the highest priority file.
Is that going to slow things down overall due to the board having more work to do?

Yes, but the effect should be small.
Config files are only read when you switch preset, and adding a few milliseconds to the time it takes to switch presets shouldn’t be a big deal.

1 Like