ProffieOS 8.4 beta (call for testers!)

Seems like most sites things that Aqua is #00ffff:

https://colors.calculatorbox.com/library/aqua

which is same as cyan.

https://colors.calculatorbox.com/library/cyan

1 Like

The Style Editor also has both Aqua and Cyan as 0,255,255.

1 Like

If that’s going to be the case let’s simply delete Aqua from our colors list and kill off the redundancy. It looks to be the only one. I get it but it also doesn’t make actual sense in leaving the duplication where no other duplications exist. That would be like us using naranja along with orange.

Additionally if you ignore the standardized paint store color nonsense and see a true representation (art community etc stuff) you get similar as to what I looked up to verify.

Aqua has been there for 8 years, deleting it may break lots of existing styles, so that’s not happening.

That’s fine. I’ve voiced the suggestion. Maybe we can consider the value change Rgb<0,255,180> at some point.

To put it poetically

“As I walked upon the sand of those aqua shores I was greeted with the view of cyan waves and thousands of cerulean shouts and whispers as the waves crashed before me.”

  • Author Unknown

No, backwards compatibility is very important.
Since it’s been there for 8 years, I’m not going to change it regardless of how wrong it is now.

Cyan and Aqua aren’t the only duplicates - Green and Lime are both Rgb<0,255,0>, and I dare say there are others too.
I also raised it a while ago but the prof is right - correcting it could potentially break some people’s style codes so best left alone as simply multiple ways to skin the same cat.

You can always change it in your own ProffieOS.

Already did that last night, it’s where I got the values from. I wanted to see if anything actually would fail, which it didn’t. I’ve always tinkered with values and input custom color values into the colors.h and it was just as easy to share the updated list with the person who’s the bladestyle was for so they’re good to go now. :smiley: *I don’t even list it as a separately added color, just edited the lines.

typedef Rgb<0, 255, 180> Aqua;
//typedef Rgb<0, 255, 255> Aqua;

FWIW, if you have particular RGB values you want, why not just use Rgb<> in the style code, then it will ALWAYS remain the same on any OS version for any user, that’s what I do in the library for custom colors.

Changing values for existing named styles in custom code seems like a recipe for inconsistency across users and OS versions, just sayin’.

I normally do it’s just this time the person requested colors by their stated OS name so I went and looked the values up after hearing back it wasn’t displaying the two different colors correct. Since I totally got that I asked here. :+1:

Isn’t that like the exact reason I gave above to go with why I use Rgb<> instead of a name? If you wrote something with a custom value for a name then the end user would have a different result, if you just wrote something with Rgb<> the result is what was intended no matter the version of the OS the use.

If you had to mod your colors.h to change the value for Aqua, then your version will never match the main OS, but if you just use the Rgb<> value in the style then it would never be an issue for any user. :wink:

In the end just to resolve it I did and also kept it recorded this way the value is always there to reference. I asked (above) afterwards since it seemed worth checking on. :grinning:

  • Hell, I think you’re the one who suggested the 0,255,180 some years back.

*As a side topic I do find it interesting that both the official and NoSloppy’s style editors will essentially “parse” Rgb code into the recognized colors whether you wish it to or not.

As an example using one of Fett’s sections of code…

Layers<
  StripesX<Scale<HoldPeakF<Sum<EffectPulseF<EFFECT_IGNITION>,EffectPulseF<EFFECT_ALT_SOUND>>,Int<3000>,Int<3000>>,Int<4000>,Int<1800>>,Scale<HoldPeakF<Sum<EffectPulseF<EFFECT_IGNITION>,EffectPulseF<EFFECT_ALT_SOUND>>,Int<2000>,Int<4000>>,Int<-2800>,Int<-4000>>,Mix<Int<16000>,Black,RgbArg<BASE_COLOR_ARG,Rgb<0,255,255>>>,Mix<Sin<Int<20>,Int<22000>,Int<32768>>,Black,RgbArg<BASE_COLOR_ARG,Rgb<0,255,255>>>,Mix<Int<8000>,Black,RgbArg<BASE_COLOR_ARG,Rgb<0,255,255>>>>,
  AudioFlickerL<RgbArg<BASE_COLOR_ARG,Rgb<0,200,200>>>,
  

When you click “Layers” on the right dropdown you get switched to this. Note it keeps the other non-spec values but I can see maybe where the user questioned stuff and I ended up seeing what was up.

Layers<
  StripesX<Scale<HoldPeakF<Sum<EffectPulseF<EFFECT_IGNITION>,EffectPulseF<EFFECT_ALT_SOUND>>,Int<3000>,Int<3000>>,Int<4000>,Int<1800>>,Scale<HoldPeakF<Sum<EffectPulseF<EFFECT_IGNITION>,EffectPulseF<EFFECT_ALT_SOUND>>,Int<2000>,Int<4000>>,Int<-2800>,Int<-4000>>,Mix<Int<16000>,Black,RgbArg<BASE_COLOR_ARG,Cyan>>,Mix<Sin<Int<20>,Int<22000>,Int<32768>>,Black,RgbArg<BASE_COLOR_ARG,Cyan>>,Mix<Int<8000>,Black,RgbArg<BASE_COLOR_ARG,Cyan>>>,
  AudioFlickerL<RgbArg<BASE_COLOR_ARG,Rgb<0,200,200>>>,

@Fett263

Main blade is switching just fine between lengths, but the second blade (accents) turns off when selecting array 1. Array 0 remains fine when I switch back, with the second blade working.

TOP and BladeArray:

#ifdef CONFIG_TOP
#include "proffieboard_v3_config.h"
#define NUM_BLADES 2
#define NUM_BUTTONS 2
const unsigned int maxLedsPerStrip = 144;
#define EXTRA_COLOR_BUFFER_SPACE 60
#define VOLUME 1250
#define CLASH_THRESHOLD_G 1
#define ENABLE_AUDIO
#define ENABLE_MOTION
#define ENABLE_WS2811
#define ENABLE_SD
#define KILL_OLD_PLAYERS
#define FILTER_CUTOFF_FREQUENCY 100
#define FILTER_ORDER 8
#define MOTION_TIMEOUT 60 * 5 * 1000
#define IDLE_OFF_TIME 60 * 5 * 1000
#define DISABLE_BASIC_PARSER_STYLES
//#define DISABLE_DIAGNOSTIC_COMMANDS
#define DISABLE_TALKIE
#define ENABLE_ALL_EDIT_OPTIONS
#define NO_REPEAT_RANDOM
#define COLOR_CHANGE_DIRECT
#define FETT263_EDIT_SETTINGS_MENU
#define FETT263_SPECIAL_ABILITIES
#define FETT263_SPIN_MODE
#define FETT263_DISABLE_CHANGE_FONT
#define FETT263_DISABLE_CHANGE_STYLE
#define FETT263_USE_BC_MELT_STAB
#define FETT263_LOCKUP_DELAY 200
#define FETT263_BM_CLASH_DETECT 6
#define FETT263_SWING_ON
#define FETT263_SWING_ON_SPEED 400
#define FETT263_SWING_ON_NO_BM
#define FETT263_TWIST_OFF
#define SAVE_PRESET
#define FETT263_SAY_BATTERY_PERCENT
#define FETT263_MANUAL_BLADE_ARRAY
#endif

#ifdef CONFIG_PROP
#include "../props/saber_fett263_buttons.h"
#endif


//show blade 122 (KR V2)
BladeConfig blades[] = {
 { 0, WS281XBladePtr<122, bladePin, Color8::GRB, PowerPINS<bladePowerPin2, bladePowerPin3> >(),
    WS281XBladePtr<14, blade2Pin, Color8::GRB, PowerPINS<bladePowerPin6> >()
  , CONFIGARRAY(presets) },

  //battle blade 125
 { 1, WS281XBladePtr<125, bladePin, Color8::GRB, PowerPINS<bladePowerPin2, bladePowerPin3> >(),
    WS281XBladePtr<14, blade4Pin, Color8::GRB, PowerPINS<bladePowerPin6> >()
  , CONFIGARRAY(presets) },

};

#endif

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

Full config

I see the 2nd blade changes data line, is that correct?

No, no it is not. Remnant from upgrading a V2 to V3 board. Sorry about that.

Working and tested for blade length changes.

1 Like

Since there’s no arrayX.wav file on my SD card, what sound is the array selector defaulting to? When I use arrayX.wav files, do they go in the common folder? I’m assuming the X gets replaced with the array number, is that correct?

I have a lot more questions but want to read a little futher. Very interesting process!

It should look for bladein.wav or font.wav

Either - in the font if you want a specific sound per preset or in common if you want it shared.
Yes, if you have the same number of files as arrays then they’d be used by number if not, it will use closest or if you only have one it would just use that.

1 Like