OS8 ProffieOS Menu System

ProffieOS
1

Not to be confused with Fett263’s Edit Mode settings which are used with the saber_fett263_buttons.h prop file, this is OS based menus.
While similar in functionality, how they work under the hood is very different.

That said, @profezzorn I just tried things out for the first time. It’s nice to see all that code “come to life” and to see it make sense, as well as a relief that it’s not complicated to use.
My initial experience is as follows.
Edit Settings:
Note that msetting.wav (“Edit Settings”) has an intentional 1 second of silence at the front end. This is because Edit Mode uses it while blade is on, and it happens simultaneously as an ignition. The breathing space prevents the prompt from being drowned out by the out.wav.
Because of this, there’s a pseudo-lag to that prompt playing amongst silence.
We may want to make another version for this menu system.

Volume menu constantly reads out the current volume percentage, which makes sense so that you have something to listen to and evaluate, just takes some getting used to. Also, I love being able to visually see the level on the blade using EFFECT_VOLUME_LEVEL with my prop’s current Volume menu version, so I’m curious how that might be able to get implemented.

Blade length - From what I see it looks like it should be doing a LengthFinder<> kind of thing with a lit pixel, no? I’m not seeing that.
It does respect the max length set in the BladeConfig, and i notice that it wraps around from the end back to the beginning.
Is there any way to add some acceleration curve into it so that if you want to go from 30 to 110 you don’t need to click all of the steps one at a time, like a jump by 5 or 10 based on rotation speed?

Edit Presets:
I didn’t mess with Preset editing stuff really, just perused the menu. Once there’s a visual template of what’s in what menu and some documentation on how that works I can test further.
However, that’s not something I’d likely use personally, so I probably won’t have much opinion on it.

1 Like
2

All valid concerns.

Agreed.

Does that work even when the blade is off?

Yes, it’s supposed to, I’ll take a look at it…

Obviously it’s possible. I have some ideas that I can play around with.

You mean something like this? (Although I also need to add explanations for what some of these things do obviously.)

g TopMenu Top Menu Edit Presets Settings Settings Settings Volume SD Access Dimming Clash Threshold Blade Length TopMenu:s->Settings:top Edit Preset Edit Preset Select Font SelectTrack Edit Style 1 Edit Style 2 Edit Style 3 Move Preset up Move Preset Down Select Preset Insert Preset Delete Preset TopMenu:ep->Edit Preset:top Edit Style Edit Style Style Settings Select Style Apply Colors Apply Settings Reset Change Style Edit Preset:style1->Edit Style:top Edit Preset:style2->Edit Style:top Edit Preset:style3->Edit Style:top Style Settings Style Settings Base Color Alt Color Arg Style Option Arg Ignition Option Arg Ignition Time Arg ... Edit Style:args->Style Settings:top Color Menu Color Menu Edit Hue Edit Brightness Adjust Red Adjust Green Adjust Blue Select Color Use Selected Reset Color Save Style Settings:col->Color Menu:top Style Settings:aca->Color Menu:top

There are some open questions like, maybe I should skip the top menu and just make “Edit Preset” a sub-menu of the settings menu?

3

From the blade style code, yeah. Works like a charm. It just needs to sit above the InOutL like preons and postoffs.

I’d say categorically it makes sense to choose either a settings branch or a presets branch as the top menu like it does now.
As per my statement above, I personally probably wouldn’t need/want the presets editing stuff, and I didn’t know the hierarchy before just trying it, hence why I was shortcutting right to the Blade Length menu. But now finding the landing point on entering is Edit Settings, and finding what I wanted plus Volume and SD access in the same branch, I’ll probably look at all that work tonight an exercise in understanding, and just leave it as EnterMenu() like i have it now.
*Edit - I found it starts the top menu where you left off last when exiting. that’s cool IMO.

4

Ok, I have:

  1. added EFFECT_VOLUME_LEVEL (bonus, the location is set to the volume percentage)
  2. Fixed a whole bunch of stuff in the blade length menu
  3. made a basic accelerator so that if you twist really fast, it moves even faster

This is exactly the use case for the SettingsOnlyMenuSpec.
I think I’m going to make a “VolumeOnlyMenuSpec” as well.

Next up: Alternate V2 “Edit Settings” sound file.

5

Now that I think about it, it seems like we might want two defines for users to control the menu system.

So far, I’ve only been using the SPEC to define which menus to use. My plan was to create default SPECs which use common choices, like “default menus”, “only settings menus”, or “only volume menu”.

However, it just occurred to me that prop makers probably want to provide alternate versions of these SPECs so that they can add their own settings to the settings menu. However, with the current setup, prop makers would then need to make “volume-only” and “only settings” versions of their specs as well. Not particularly hard, but it could multiply and grow into a hassle pretty quickly.

I can think of two ways to fix this:

  1. I can make templates that create a volume-only spec from a full-featured spec, and another template that creates an “settings only” spec from a full-featured SPEC template. If you wanted the settings-only version of the blaster spec, you would do something like:
#define MENU_SPEC_TEMPLATE SettingsMenuOnlySPEC<BlasterMenuSpec>::T
  1. I could make a define that lets you choose a menu other than “TopMenu” as your menu entrance point. Then it would look something like:
#define MENU_SPEC_TEMPLATE BlasterMenuSpec
#define MENU_SPEC_TOPMENU SettingsMenu

The second one has the advantage that no extra templates has to be created, and all menus would be supported. The first one has the advantage that the template code could potentially do smart things to extract the right menu if such a thing is needed.

Any preferences?

6

Hmm, in sound_library.h, medit.wav “Edit Mode” is listed as having a 1-second silence, but msettings.wav is not. Also, I checked “english C” on my site, and it also has delays in medit.wav, but not msettings.wav

7

If so, that would still mean exiting backwards though to the top menu and out, yes?
Others can chime in, but I don’t feel a need for so many options.
Top menu as-is is good in my opinion. I like that it remembers where you last exited from. This way, frequently used is even easier to get to.

By the way, blade length shows the LED now. :+1:
I don’t see much acceleration when rotating more quickly, but

  • I don’t remember what is was like before and
  • it’s not that horrible even if it’s a little slow.

Mostly, no one would be needing to change that drastically anyway, and very infrequently at that. If it were something that affected things at all times that would be different. Like if it changes rotation in main menus and not just the blade length, then it could be bad to go too fast.
TL;DR - it seems pretty good as it is at the moment.

Well then I never sent the updated versions.
mbegin, medit, and msetting get a 1-sec silence at the from end.
Looks like we don’t even use mbegin, but nonetheless, all of the voicepacks I have have been processed that way.
I think the right thing to do would be to update the ones hosted at hubbe.net, then proceed as we were thinking we would and just make a new meditset.wav or something for use in the OS menu.

8

Yes. The stack of modes is independent of any of this.

Seems like it would be more flexible to create a separate silence wav and then have the prop play that before the option it wants. However, I haven’t thought through the compatibility implications of such a change yet…

The whole point of the sound library is to make the sounds re-usablble, including the silence in the sounds caters to a very specific use case, and makes it much more difficult to use those sounds for anything else.

9

Seems pretty straight forward to me. Below is the only place it happens.
We make an msilence.wav, and add sound_library_.SaySilence();
right above these 2 spots for SayEditSettings and SayEditMode:

Then revert all the existing prompts to have no silence (good amount of work but I have a bunch to do anyway adding new sounds for V2)
And apparently the versions you are hosting don’t need adjustment, so that much ahead of the game :slightly_smiling_face:

10

But happens if you have an old voice pack?
Or old code, but with a new voice pack?

11

This is always hard for me to conceptualize because I am on the cutting edge.

I find it weird though to imagine someone updating to new code, but trying to force using an old voicepack. Why would that happen, especially with BIG notification with the OS release that it requires V2 voicepacks? (and they’re FREE!)

Also weird to update a voicepack for no reason without updating code as well?

If have old voicepack and old code, things work.
If have new code and new voicepack, things work.
If have new code but old voicepack , should update to new voicepack to match new code.
If have old code and new voicepack, should update to new code because why wouldn’t you?

I guess what I’m saying is who’s playing this game that would find themselves in some situation where a mismatch would be a forced result?

12

My assumptions is always that users will do every combination, regardless of whether it makes sense or not.

Also, ideally I want as much backwards compatibility as possible, so I would prefer if we didn’t require that people update their voice packs. Also, if we require that people update their voice packs, we create pressure on you to replace all the old voice packs with updated ones.

One complication is that we currently have a mix of voice packs with and without silence in front of some sound.

Option 1

  1. We add msilence.wav to new voice packs. However, this would not be a V2 sound. Instead, we put it in with the V1 sounds.
  2. Any voice pack that has msilence.wav should not have any silence at the beginning of any of the sounds.
  3. We update fett263s prop to do ->SaySilence() before ->SayEditSettings() (and wherever else it is needed) We can backport this change to 7.x to increase compatibility across everything.

All new code, which depends on the V2 sound library can assume that there is no extra silence in any of the sounds.

So, now we have this matrix:

7.14 and older (fett263) 7.15 and 8.x (fett263) new V2-based code
old voicepack works works, but serial monitor will complain about missing.msilence.wav “Error in font directory”
V1 voicepack with msilence.wav no silence at some prompts works “Error in font directory”
V2 voicepack no silence at some prompts works works

Note, I don’t know if “V1 voicepack with msilence.wav” is ever going to be a thing, but I included it here for completeness, since it is a possibility.

So the only concerning combination is if you update your voice pack, but not your OS, you’ll lose the pause in the beginning, and you won’t get any warnings or messages that tell you why.

Option 2

V1 sounds which could use pauses have them, but we’ll create V2 sounds without those pauses. (And possibly also add msilence.wav, if we think we need it.) to V2.

7.14 and older new V2-based code
old voicepack works “Error in font directory”
V2 voicepack works works

This seems simpler overall, and maintains perfect compatibility, so I think this is what we’ll do…

So which sounds have a pause in the beginning in your voice packs?

13

I already easily added it to every common folder under the sun on my end in one fell swoop.
`find Voicepacks -type d -name “common” -exec cp Voicepacks/msilence.wav {} ;
Having it there doesn’t hurt. Now it would just be a matter duplicating the collection, then stripping the 1sec silence off the front for all of them. Or when you say V2 does it mean just those sounds in a folder? or actually a complete pack (assuming the latter).

mbegin, medit, and msetting
To wit, only msetting really is “shared”. “Edit Mode” is practically a trademark for Fett263 menu system, and mbegin isn’t used anyway.
Not that it’s really any more or less work, just noting it.

14

A V2 voice pack should include all V1 sounds + the V2 sounds.

15

Ok I have all the default V2 voicepacks un-silenced and msilence.wav added.
I have some work to do to get all the new sounds added, and won’t be surprised if there are a few more yet to come.
It might be hard to get the Italian Voice talent again, I might need to just get close.

16

Uhm, if that means removing the silence in the beginning of msetting/medit, then why?
I decided to go with “Option #2” above, which means keeping the silence in the beginning of those sounds and create new sounds without the extra pause.

17

I have all the V1 copies as they were.
I duplicated the V1 collection and removed the pause from the front of those prompts.
I added msilence.wav (everywhere just because)
Now the V2 collection with no pauses will have additional prompts (msdacc etc…) added to them.
So is that not right?

This could mean 2 things to me.

  1. Keep the versions of medit/msetting with the pause in V2 as well and “create new sounds” for them - meaning duplicate, remove pause and rename to new filenames. a.k.a. repurposing the existing ones by duplicating them and editing out the pause. Result = having 2 versions in the voicepack, pause and no-pause.
  2. Create separate new prompts with new names, possibly saying something different.

I’ve edited this post several times trying to be concise, I hope I am being clear.

18

That is not right.
Basically I scrapped the idea of using msilence everwhere because it causes compatibility problems. It was an idea, but after reasoning it out, I decided that it wasn’t a very good idea. That means that, medit.wav and msetting.wav should begin with ~one second of silence in all voice packs.

I’ve added a new sound in V2 called “mseting2.wav” which is “Edit Settings”, but without the padding. msilence.wav is not yet a part of V2 sounds, but can be added if we want it/need it. The code for this was checked in last night. I also updated the simple generation script to handle the padding correctly. I haven’t done the same for “Edit Mode”, since there is no code that would need that particular sound.

1 Like
19

So I’ve been contemplating adding all the ProffieOS named colors to the voice pack, and then create a menu that lets you select colors by name. However, the list is getting a bit long and might take up more memory than I would like. Also, I’m not sure how practical the menu would be if you have that many colors in it…

Then it occurred to me that I could put a text file in the font pack which has a list of colors in it. The code wouldn’t contain any list of colors, instead it would just get them from the file. Each color would also have a filename for the sound to play for that color.

This means that you could easily go edit this list and remove any colors you would never use to make the list more manageable. Not only that, but you could also easily add colors, as long as you can also provide a sound for it.

Besides making voice packs a fair amount larger, I don’t really see a drawback to doing it this way. What do you guys think?

20

As long as it doesn’t conflict with the ColorList in my prop it’s fine with me. Currently, my library and config tools are all aligned with this ColorList so everything is in synch in building and editing styles.