FONT_PATTERN discussion and understanding

ProffieOS
1

I first read about FONT_PATTERN here:

Then in the POD:

The first problem I have is with the POD itself:

  • when an asterix (*) is used in the text, instead of showing an * symbol, I will start to see text in italic starting where the first *was supposed to show and finishing when the next * was supposed to appear but doesn’t however the text is “no longer in italic” (I am using Firefox browser on Windows10 if that makes any difference)
    I know that I am not supposed to post screenshot of text (and I will be very happy to delete this screenshot) but this is what I see:

Edit: screenshot deleted.

No asterix (*) is showing in the text. I can only understand the POD because I re-read multiple times both the POD and the “gearing-up-for-os8” thread about FONT_PATTERN. By the way, the define “FONT_PATTERN” text doesn’t seem to be able to “automatically” turn itself into a link like CONFIG_TOP does.

Now that my preliminary thoughts about FONT_PATTERN are out of the way, I will try my best to explain what I thought it would be able to do when I first read about it, what I think it actually does & what I think it “should” be able to do.

  • what I thought it would do:
    1. Let’s imagine OS8.x is live (no longer in Beta testing)
    2. the config generator has been updated to the latest OS8.x bells and whistles
    3. a new to ProffieOS user comes along and make his first ever simple OS8 config with 1 blade and 2 buttons. I would imagine it would look like this:
// ProffieOS8 config
#ifdef CONFIG_TOP
#include "proffieboard_v3_config.h"
#define NUM_BLADES 1
#define NUM_BUTTONS 2
#define VOLUME 1000
const unsigned int maxLedsPerStrip = 144;
#define CLASH_THRESHOLD_G 1.0
                                                 // <- note the "missing defines" that are no longer here because they are "ON" by default in OS8, including the new #define FONT_PATTERN "*;common"
#endif

#ifdef CONFIG_PRESETS
Preset presets[] = {
   { "TeensySF", "tracks/venus.wav",
    StyleNormalPtr<CYAN, WHITE, 300, 800>(), "cyan"},
   { "SmthJedi", "tracks/mars.wav",
    StylePtr<InOutSparkTip<EASYBLADE(BLUE, WHITE), 300, 800> >(), "blue"},
   { "SmthGrey", "tracks/mercury.wav",
    StyleFirePtr<RED, YELLOW>(), "fire"},
   { "SmthFuzz", "tracks/uranus.wav",
    StyleNormalPtr<RED, WHITE, 300, 800>(), "red"},
   { "RgueCmdr", "tracks/venus.wav",
    StyleFirePtr<BLUE, CYAN>(), "blue fire"},
   { "TthCrstl", "tracks/mars.wav",
    StylePtr<InOutHelper<EASYBLADE(OnSpark<GREEN>, WHITE), 300, 800> >(), "green"},
   { "TeensySF", "tracks/mercury.wav",
    StyleNormalPtr<WHITE, RED, 300, 800, RED>(), "white"},
   { "SmthJedi", "tracks/uranus.wav",
    StyleNormalPtr<AudioFlicker<YELLOW, WHITE>, BLUE, 300, 800>(), "yellow"},
   { "SmthGrey", "tracks/venus.wav",
    StylePtr<InOutSparkTip<EASYBLADE(MAGENTA, WHITE), 300, 800> >(), "magenta"},
   { "SmthFuzz", "tracks/mars.wav",
    StyleNormalPtr<Gradient<RED, BLUE>, Gradient<CYAN, YELLOW>, 300, 800>(), "gradient"},
   { "RgueCmdr", "tracks/mercury.wav",
    StyleRainbowPtr<300, 800>(), "rainbow"},
   { "TthCrstl", "tracks/uranus.wav",
    StyleStrobePtr<WHITE, Rainbow, 15, 300, 800>(), "strobe"},
   { "TeensySF", "tracks/venus.wav",
    &style_pov, "POV"},
   { "SmthJedi", "tracks/mars.wav",
    &style_charging, "Battery\nLevel"}
};
BladeConfig blades[] = {
 { 0, WS281XBladePtr<144, bladePin, Color8::GRB, PowerPINS<bladePowerPin2, bladePowerPin3> >(), CONFIGARRAY(presets) },
};
#endif

#ifdef CONFIG_BUTTONS
Button PowerButton(BUTTON_POWER, powerButtonPin, "pow");
Button AuxButton(BUTTON_AUX, auxPin, "aux");
#endif

Then that user would add a CONFIG_PROP section with a prop file that needs a voicepack.
4) that same user would have downloaded and “installed” the default SD font/tracks package on his SD card and a voicepack in a common folder on his SD card as well (let’s just say for the sake of arguments that all the files “that should be on his SD-card” are exactly where they should be, “lucky first try user”)
5) he is not aware that the default presets could and should be changed from “TeensySF” to “TeensySF;common” so he doesn’t do it.
6) because of the hidden “magic” of FONT_PATTERN, everything worked perfectly on the first try. What a lucky first time user!

That is what I was expecting/hoping FONT_PATTERN would do after reading the “gearing-up-for-os8” thread for the first time. I don’t think it can do that?

  • what I now think it does:

    • if a user wants his common folder to be named anything else than “common”, let’s use “_my_common” for this discussion.
    • That same user has all his presets programmed correctly: “TeensySF;_my_common”, “SmthJedi;_my_common”, …
    • and he has #define FONT_PATTERN "*;_my_common" in his config.
    • he starts using Edit Mode via one of the MENU_SPEC_TEMPLATE option and edit his presets. His edited NewFont preset will have "NewFont;_my_common" as a search path for his “*.wav” files.
    • I don’t know if this will also apply with saber_fett263_buttons.h if #define FETT263_EDIT_MODE_MENU is defined instead of MENU_SPEC_TEMPLATE or not?

  • what I whish it could do: everything I wrote about above, plus be some sort of an “OS wide *.wav (and maybe even*.bmp/pbm/pqf) global search path” for any non-font specific file like voicepack/sound_library sounds, error sounds, multi_prop sounds, any and all spoken digits/numbers, battery, …
    First ProffieOS looks in the font folder, then in the FONT_PATTERN “default folder” no matter if it is in the preset “font folder path” or not. And then only after that a beeper or talkie sound could be initiated if the *.wav file is missing. Maybe I am dreaming ?

2

This should be fixed now.

This is correct.

I think the fett263 menus still expect “*;common”, regardless of FONT_PATTERN for now.

I suppose it could work like that.
It would make things a little simpler, and since everything has to follow the same pattern anyways, it might make more sense. The only reason I didn’t make it work like that is that the fett263 prop already expects “*;common” everywhere.

3

Perfect, much better.

I am not sure I understand this sentence:
“Note that, in order for ProffieOS to be able to extract the font directory from the font search path, all presets in your config file must have font search paths that match the pattern.”
Does that mean that if one preset has a different font search path then all the others, will that “break” the FONT_PATTERN behavior for all presets or just for that one preset with a different font search path pattern.

I guess this the line responsible for that:

How would it need to be changed to become compatible with FONT_PATTERN ?

5

basically, it would need to remove line 2985 and 2986 and do this instead:

  current_preset_.font = format_pattern(FONT_PATTERN, font);
1 Like
6

Thank you @profezzorn , I have already made the change on my local copy. I hope that @Fett263 will do the same on the master copy. I can see this as a great step forward to greatly reduce the size of the talkies code and replace the errors sounds with higher quality (and customizable) “.wav” errors. :crossed_fingers:t2:

7

How?
Why?
Whut?

8

As a first step forward then. If FONT_PATTERN can be used to find most error .wav as an OS wide search path, independently of any props. Then most talkie error can be replaced by a “*.wav” file, as discussed in the other thread. Or did I get what could be possible with FONT_PATTERN completely wrong ?

9

FONT_PATTERN isn’t used to find anything, at least not directly.
FONT_PATTERN is only used when you use a menu to modify a preset.
I think what you want is similar to font path, but different.
I suspect that what you want is actually really simple:

Just try to play a wav file falling back on talkie or beeps. (name of wav depends on the error.)
If the wav doesn’t doesn’t exist or can’t be found, just fall back on what we already have.

This has been suggested before, as a way to customize the error messages, but I pointed out that error messages really shouldn’t occur once you have finished your saber, and we don’t need vader telling us that there is an error in your font directory while working on the saber.

However, make sense as a way to save memory without having to rely on beep codes.
Of course, if you mess up your fonts and voice packs somehow so that you don’t have the right wav files, you still get beep codes and you might have to use the serial monitor to figure out what’s wrong.

FONT_PATH has no impact on this.

10

Not really following what’s being asked. If a change to my prop is helpful to users and doesn’t impact existing functionality, I’m fine with it, but I’m not really sure what this is about or if it’s actually needed.

11

That is exactly what I want.

No without having to rely on talkie codes as they take a lot of memory. beep codes are retained as a fall back because they only take very little memory, however beep codes can be hard to differentiate.

I agree for “error_in_blade_array”, once the saber is finished, that error shouldn’t occur. My saber will never be finished though because I’ll keep changing the fonts so all the other errors can and will occur. And I would rather have Vader telling me what that error is than the talkies telling me what’s wrong.

When FONT_PATH was introduced in the Gearing up for OS8 thread, you had asked:

But you never got an answer on how to make your edit mode compatible with that define.
And the answer is:

I always thought that having to name my common folder as “common” to be compatible with your prop (instead of “_common” or “voicepack”, or what ever the user preference is) was a limitation in your prop.

With FONT_PATTERN, that limitation disappears if you choose to make your edit mode compatible with FONT_PATTERN. And it will be transparent to the user because FONT_PATTERN will default to “*;common” if not defined in the config.

12

If we had this, would you still want/need the “minimal talkie”?

13

I would say yes and no:

  • yes I would want it because “sd_card_not_found” can’t ever be played from the SD-card, and I would rather have a good military “No.S.D” than a beeper,
  • but no I wouldn’t need it because with just one error that would still need to be at least a beeper, it would be easy enough to identify what that error is. I would however change the beeper to an “S-O-S”, at least on my local copy, because that I can always recognize.

So to fully answer your question, if we had “that”, the minimal talkie wouldn’t be absolutely necessary, just nice to have as an option. IMHO