Config.h / Style / Workbench Questions

ProffieOS
1

Couple questions about config.h / styles and the workbench. It’s possible these have been answered, but I couldn’t find anything with a search that quite hit the spot I needed it to:

I’m working with an UltimateWorks Proffie Heart Core (Porffieboard 2.2) and it’s flashed to ProffieOS 6.7. Everything works fine, I’m now at the ‘mess around with styles until your eyes fall out’ stage of learning to use a Proffie Board.

Originally the config had been setup for 3 blades from the manufacturer: 144 led neopixel blade, 8 led chassis accent, accent LED. I don’t have accent LEDs, so that was simple enough to take out. I love having the mini version of the saber on the chassis leds, so I want to be able to use that, however I’m also trying to save space. Lately, I’ve been doing a lot of my style tinkering in the Proffie Workbench and I’ve noticed it’s easy to just assign whichever preset style to whichever of the two blades through there (yay!).

What I’m wondering is this - In the interest of slimming my config.h down as much as possible (and having more space to play on the Poffieboard itself is there a way within a given style in my config.h to ONLY have a single blade defined that would still let the second blade show up on the Workbench? In a roundabout way, I’ve managed to have some “empty” styles (builtin 0 1 has style, builtin 0 2 is basically blank) and that’s worked, but I think that only worked because I’d previously flashed with both defined. Would be keen if there were a way to define individual styles and then use the Workbench to assign to whichever “blade” I want, and there might be, but I’m a noob.

Given that, I also have a BUNCH of builtins that show up on the Workbench - for a while it was 3 per builtin until I removed the accent LED stuff, but it still has buitlin # 1 and builtin # 2 for each preset and it’s a little hairy. Is there a way to assign a name to those builtins (similar to how the basic parser styles have names like Standard, Advanced, Rainbow, etc?

Ultimately I’m looking for ways to clean up my config.h as much as possible (so I can cram more styles in there) AND declutter what it ends up looking like on the Workbench AND have readable names instead of just “builtin #” for each so I don’t have to try and remember which is which.

My pipe dream would just be to have some lovely marriage of Fett263’s style builder and the Workbench where you don’t even need to worry about fussing with config.h for styles and can just built in the builder and assign it to a font in the Workbench.

Appreciate any guidance y’all can give

2

I’ll try to answer, although a little confused on a few things.

Let’s start at the top, Workbench can only edit what exists on the board already (from a previous upload). This goes for styles, colors, options, etc. (Fonts would be the exception since they reside on your SD outside the OS). So to be able to change a style for any given preset it had to have been uploaded to some preset via your config previously.

This is also why we can’t integrate the library and the Workbench, you have to first upload the style code the library generates to your board via Arduino for it to exist, then once it exists on the board it can be used in any preset you want. There’s no way to take the style code directly from the library to the Workbench.

If you’re asking if you can remove your 2nd blade from your config but add it back via Workbench, then the answer is “No”, the blade exists in more than just the style, your BladeConfig needs to know the second blade exists to include the code necessary to run it, so it must be there in your config and uploaded via Arduino for it to exist to be edited.

You can reduce the “repetition” in your config if you are just reusing the same styles in multiple presets via a “using”, the Library can output this for you, see this thread:

This will allow you to simplify the presets where you’re repeating the same styles.

You can also use the library to build “Option Styles” this will make it so you can edit the style via “Style Option” instead of “builtin 01” as you can combine several base styles into one and designate the base style via “Style Option”, this is handled by the library as well and also saves additional memory as it reuses other layers that would normally be replicated. You can build these from the first screen of the library by adding additional “Style Options” before going into the “Preview / Enhancement Screen” and you can generate the “Using Function” as noted above to then have the style options built out to be repeated.

Note, the library will generate the copyright comment with the assigned Style Option # for each selected base style, the comments generated by the library are your receipt and are meant to be used with either Edit Mode or Workbench to help you identify the style or option.
“builtin 0 1” refers to the style for first preset (0) and first blade (1) so you can keep a copy of your config to determine which style that represents. I’m not sure there’d be a way to rename the “builtin 0 1” etc. as the OS reads those to determine the style code to use.

I discussed more “space saving” with Megtooth in this video, it might be worth a watch as well.

1 Like
3

Thanks for the really thorough answer. Aside: All the work you do for saber stuff is amazing and invaluable you deserve all the thanks.

I understand it’s not possible to have a direct pipeline from the library to the Workbench as everything currently exists - It’s just a “maybe someday” wish.

As for the two blade thing, let me see if I can clarify what I’m asking a little:

I have #define NUM_BLADES 2 in the CONFIG_TOP portion of my file and I have the blades defined below with:

BladeConfig blades[] = {
 { 0, WS281XBladePtr<144, bladePin, Color8::GRB, PowerPINS<bladePowerPin2, bladePowerPin3> >(),
    WS281XBladePtr<8, blade2Pin, Color8::GRB, PowerPINS<bladePowerPin4> >(),
	CONFIGARRAY(presets) },

Which was generated from this page Proffieboard V2 and using the info provided by UltimateWorks.

Within a given style, this is the general format I’ve used:

   { "YELLOW;common", "common/tracks/uranus.wav",
    StyleNormalPtr<AudioFlicker<YELLOW, WHITE>, BLUE, 300, 800>(), //Blade 1
    StyleNormalPtr<AudioFlicker<YELLOW, WHITE>, BLUE, 300, 800>(), //Blade 2
    },

Which within the Workbench would show up as “Yellow” under presets, and the Styles would list as Style 1 Builtin 0 1 and Style 2 Builtin 0 2 when editing a preset.

Since I, typically, just use the same style for both the blade and the chassis LEDs, most of my styles just have the same thing twice. Looking (briefly) at what you linked, it sounds like I’d be able to use the using thing to repeat more complicated styles instead of just copy/pasting the code and it sounds like that results in a reduction of space used on the Proffieboard memory - did I understand that correctly? If that’s the case, then I’m good (and just need to reach myself to do it that way).

If NOT, I’m wondering if you can just leave out the second blade info in the style and not have everything freak the heck out:

   { "YELLOW;common", "common/tracks/uranus.wav",
    StyleNormalPtr<AudioFlicker<YELLOW, WHITE>, BLUE, 300, 800>(), //Blade 1
    },

Since you’d be able to assign that “builtin 0 1” to both styles within the Workbench. In part, I’m trying to avoid having a whole TON of builtin’s listed under styles in the workbench because there are two for every preset in the config file.

Being able to rename the “builtin 0 1” and such would mostly be for conveniences sake, more than anything. I only asked about it as there are the built in presets like Standard, Advanced, Rainbow, Flame, etc. that have unique names. If that was something user settable for their own styles, it would be handy (Could have one called Twins, for example, that was built off your style for the twins from Visions). Not a big deal to just reference the config file for that info, it would just be handy.

4

Also thanks for the link to the video, I’ll give it a more thorough watch when I’m not engaging in saber silliness between clients at work. :smiley:

5

How about just StylePtr<Black>() for the dead blades and then assign it a different style in Workbench. That’s going to use like no memory.
As far as what they’re called, you should be using the “name” argument at the end of every style. Look at the default. It has like cyan and blue and fire as the name of the preset in quotes at the very last bit of the preset. That’s the name that shows up in Workbench

6

Yes, the using would cover this. In the builtin code it would still be “builtin 0 1” and “builtin 0 2” but they would actually just be the same style code if you used the using for both.
NOTE: in Edit Mode the styles for each blade cannot be swapped, so blade 1 will only have access to the builtin styles for blade 1 in the config and blade 2 would only have access to builtin styles for blade 2, this is because most often secondary blades, accents or crystal chambers have much more simplified styles so to keep the primary blade and other “blades” styles aligned Edit Mode only looks at the builtin code for the specified blade. (I discuss setting up a single “Accent” style with multiple Options and repeating in the video above), this will typically allow you to fit even more Primary Blade styles into your config, as accents can’t really use layers like Drag, Melt, etc. so having primary styles assigned to them wastes a bit of memory on features those blade can’t utilize.
Workbench let’s you cross blade styles so it works a little differently.

You keep referring to “Standard”, “Rainbow” etc. which leads me to believe you missed this define, I would highly recommend adding this define as it will save a significant amount of space in your config.

#define DISABLE_BASIC_PARSER_STYLES

and if you haven’t read this page I would also recommend:

The “Standard”, “Rainbow” etc are hardcoded into the OS by those names as basic parser styles but they are missing a lot of the current functionality and take up more room in your OS particularly if you don’t use. I would use the above define and then generate an OS6 compatible version from the library, it will both save additional room and give you the current features and more editing capabilities than the basic parser styles. They will become “builtin” as well but that’s where the copyright comments in your config come into play again. If you use the above define and build library versions of the Rainbow, Flame, etc. you’ll actually fit even more in your config than you are now in my experience.
As noted, I do not know if it would be possible to rename the “builtin” styles individually as that is used by the OS via your presets.ini, that would be a question for @profezzorn , but in the interim the copyright comment from the library will let you keep track in your config of which style is which, hence why it is generated in the first place.

7

I would be cautious with this, as if you ever went to edit via Edit Mode this “blade” would only ever be OFF and once you go into editing it will turn the blade Off and not allow you to make edits to it. I would recommend either a single using for the 2nd blade that’s shared across presets or a using for styles used on the primary blade. Having a “black” blade as a builtin is less than ideal in my opinion.

8

@NoSloppy

Re: StylePtr<Black>() - going with what @Fett263 says below, going with ‘using’ looks like the better option.

The name argument sets the name of the preset (which I do use, just not in the example above, which I wanted to be barebones), it does not, however, change the name of the style when you’re in edit mode on the Workbench.

@Fett263
Noted on the styles for Edit Mode, I mainly tinker via the Workbench, so it’s good to know that difference between the two exists, and is another case for going with the ‘using’ option just to have the option exist. Also, that page is how I got the board setup for Edit Mode and Workbench I love your documentation.

As far as #define DISABLE_BASIC_PARSER_STYLES goes, I’ve got that in my config. I was only referring to those basic styles to give an example of what I meant when asking about renaming ‘builtin 0 1’ etc. to something more plain text readable.

My assumption being that Workbench gets the label from someplace and depending on where that is, it might technically be something the end user could change or add to. It sounds like it’s buried in the OS code someplace and not something that can be set within the config.h file.

Knowing that the library versions of those basic styles do more and take less is good to know - I’ll probably go through and create those to have as styles to chose from. Makes me wonder if there were some way to build a library similar to saber_fett263_buttons.h (or even add to that) in a way that would, functionally speaking, replace the basic parser styles with the new, more efficient versions.

9

The basic parser styles are built into the OS and the label is built in as well (when you don’t use the disable define) so the names are not something the user sets.

I would keep them disabled and just generate library versions, they will have more features.

The library is built to allow this, since every user has completely different preferences and there’s millions of possible combinations of effects I built the library to let users customize and combine things to their personal taste. Building in my own “parser” styles would be severely limiting, the concept behind the “Enhance” capabilities and all of the Color and Style Modifiers built into the library is to let every user truly customize their sabers to their exact perferences and tastes without needing to actually “code” everything.

Not sure if profezzorn has a way to change “builtin 0 1” in the Workbench or not, but in my opinion building new “parser” styles into the OS would be a step backwards from what I built the library to do. The level of customization the library offers is more valuable than having a label on the style, and I generate the “name” and all of the options and enhancements into that copyright comment so that you have a receipt for everything right in your config to make editing in either Edit Mode or Workbench less of a guessing game :wink:

1 Like
10

The real step forward here is going to be when we get boards with more memory.
All of these concerns would be moot if we had a few hundred kb more flash memory.

In the meantime, please add labels to your presets; it’s not required, but it should make things work better in the workbench and elsewhere.

2 Likes
11

@Fett263
More options, ultimately, is always going to be better. 100% agree.

For the “builtin 0 1” in Workbench, I also wholly acknowledge this is absolutely my own obsessive-compulsive tendency to want to be able to organize things in a way that’s easy to use for me, and for me, being able to name those within the Workbench space instead of having to refer to another document would just be nice.

I also hung out with folks that spent several hundred hours coding all the old Rolemaster data into an app so our D&D group didn’t have to cross reference multiple books / tables / etc.

I’d be shocked if there weren’t some way to add the functionality to the Workbench and to keep that info in the preset.ini or even a styles.ini or builtin.ini - literally just a cosmetic alias for the end user.

Whether making that happen is useful to enough people or anyone other than me at all such that it would be worth @profezzorn 's time is a completely different issue. :slight_smile:

The fact that your style library and his workbench tool even do what they do already is a HUGE help to the community.

@profezzorn
Well, yes. As likely as soon as an updated Proffieboard that does this is a thing one can buy, I will probably do so, just like upgrading the board on my 3d printer.

1 Like
12

For some reason I thought the workbench already used the labels to make the styles easier to read, but now that I look at the code, I don’t see it, so maybe I thought about doing it that way, but didn’t?

2 Likes
13

It uses the labels from the styles to name the Presets and label them in the ini file. When you go into edit mode and you’re using the Style drop down, it lists the default styles (if you havent disabled them) and then lists the ones from your styles as builtin 0 1, builtin 0 2, builtin 1 1, builtin 1 2, etc. If it pulled the style name from the preset that would help a ton to remember which style you were picking. As it works right now, I’ve keep my config.h open and I’ve got comments for each style with their number so I know what the heck builtin #whatever goes to

14

Oh yeah…I should have read slower. Correct. Preset name, not styles. Of course.

2 Likes