The RGB analysis makes sense. You really dialed that one in.
I have compared as much code as I can with a number of different analysis programs. It is beyond my skill set.
I’m not going to stress until OS7 and S3 meet. Maybe they won’t mix and their unnecessary messing around will need to end. If I can cleanly upgrade to OS7, then all is well. If not…
I didn’t mean support from S3. They have been responsive, to a point. I meant people who don’t want to rely on “mother sabertrio” to fix all their issues. Some of us want to do stuff on our own. Vaguely similar to the Apple vs Android argument.
I’m content to leave things as is unless Fett can quickly line item the kyber dial / color change conflict. However, he’s got enough with OS7 integration to fuss with a almost non-issue at the moment.
What’s preventing you from just doing that then?
You don’t need ANY of that stuff to have it work.
Just upload a fresh clean copy of ProffieOS, don’t use their prop file, and that’s it?
They did mention on the support page to download their 3.02 proffie config that moving forwards they’ll ensure full compatibility with future open source releases, so that’ll likely be a non-issue moving forwards.
I’ve tried. The whole purpose of this thread was to diagnose why my activation button LED reacts to the blade color choice when using all default ProffieOS. It shouldn’t unless I tell it to, right?
So the end question is, why can’t I use saber_fett263_buttons.h and have my activation button accent LED stay lit regardless of the blade color choice? The option to have an accent LED react (or not react) to the main blade is in Fett’s style builder options. But it doesn’t work. I’ve tried everything. I must use saber_sabertrio_buttons.h and thus have their button config options, unless I want an unmedicated bipolar LED.
If I didn’t have that LED around the button, I wouldn’t care. But my sabers do have it. I shouldn’t need to abandon a feature.
Their approach is only valid to a single build, it has no value in the main OS. As it would only apply to a saber built and wired identically, if any user with a different set up or BladeConfig attempted to do what they were doing it would make it so they could never change any SubBlades, accents, PCB or other blades besides the first, so it has no real use in the main OS.
Color Change in my prop is actually controlled by the style itself because there are multiple methods of color changing in OS6 and 7. #1 = Color Wheel (affects all colors on all blades except for White and Black, this is built into the OS by default.) #2 = Variation (allows you to specify which colors in a style should be controlled by the default Color Wheel - this is typical to OS5 styles) #3 = Color Change (this is a style that allows you to set predefined colors into a style to rotate through, this overrides Color Wheel, Variation and Color Editing) #4 = Color Editing (OS6 - allows for specific colors on specific blades to each be individually edited via Edit Mode or ProffieOS Workbench, uses ARG values to determine which colors are edited and which menu controls the editing) (Color Editing cannot be used with ColorWheel or Variation as they are very different mechanisms, ColorWheel is a universal change)
So my prop reads the styles in the preset and adjusts the “ColorChange” method used accordingly so you can have different presets act differently.
If you have Editable styles with ARG values in a preset my prop has to use Color List (via Edit Colors capability) although holding down PWR while turning will allow you to use Color Zoom to fine tune to an exact color. This is applied to ALL blades to match expected behavior of Color Wheel and Color Change methods defaulted in ProffieOS, which is all blades that contain BASE_COLOR_ARG are changed together because every build is different and the number of blades, sub blades and the order of those blades in the array varies from user to user.
If you want to edit colors on one blade at a time you should use Edit Mode or ProffieOS Workbench (this will let each blade be handled separately as long as they are using ARG values).
Now if you don’t want a blade to be affected by Color List simply don’t use a style with BASE_COLOR_ARG and it won’t actually be edited
If you remove all ARG values in a style, then my prop will check for the first 3 instances listed above and react accordingly.
See above reply for details, simply remove the BASE_COLOR_ARG value from the style that you don’t want affected, then the Color List can’t change it
You could also just change the BASE_COLOR_ARG in that style to ALT_COLOR_ARG and keep it editable via Edit Mode and Workbench without being affected by the ColorChange method.
Okay, I understand where you’re going with this. I believe.
Let me see if I get the gist in more simpleton terms.
This LED behavior when changing colors via the color wheel is affecting every style. If I remove said value BASE_COLOR_ARG from every affeded style, which is all of them, then my blade will be locked into the pre set color. The blade color will only be editable via ProffieOS Workbench (not particularly helpful if not in front of a computer with cables), OR the more advanced Edit Mode (which can be enabled or disabled via #define). Color change on the fly is thus not possible in the ‘standard’ non-edit mode color wheel.
Remove or change BASE_COLOR_ARG from the styles you DON’T want to be affected.
Note, you have to change the entire RgbArg<> portion if you are removing.
It’s easier to just swap BASE_COLOR_ARG to ALT_COLOR_ARG in the styles you don’t want affected by ColorChange method. They would still be editable under Alt Color this way.
Find and replace BASE_COLOR_ARG with ALT_COLOR_ARG
I would need to do that to every style, given I don’t actually want a flaky LED on any style. I assume that’s what you mean.
For Sabertrio sabers, every soundfonts and accompanying blade style ends with
StylePtr<WHITE>()
That was established and confirmed before.
I’ll give this find and replace a go on a simple test config, also replacing the currently needed file saber_sabertrio_buttons.h with saber_fett263_buttons.h since that’s kind of the whole point of this thread.
Thank you for explaining why this situation is specific to Sabertrio sabers. They are wired in such a way that this editing of styles (BASE_COLOR_ARG to ALT_COLOR_ARG) is necessary to maintain full functionality when using saber_fett263_buttons.h
Sorry, I haven’t kept up on this thread, TBH as soon as I see “SaberTrio” I bail on the thread as I already wasted enough of my own time trying to sort out issues they introduced for various users. I don’t think they actually understand Proffieboard or the users who want to use it so I leave anything related to their sabers for them to sort out as they’ve created the problems for their users.
If you do a Find and Replace on BASE_COLOR_ARG and replace with ALT_COLOR_ARG you’ll disable ColorChange for all of your blades in all presets, which is not what I think you want.
Since the LED is just “On” you don’t need any style for it, just use:
StylePtr<White>()
as the second style in each preset and it will just always stay on regardless of prop.
Yeah, I’m one of those problem children. Dont mean to be, but I’m a tech guy. I like to play with stuff.
I don’t blame you for bailing. I’m ready to bail. Had I known they were such a pain to do anything with, I’d have bought elsewhere. Serves me right for wanting to do cool things with my sabers.
I’ll carefully study and play around with the information you posted. First glance, I’m obviously getting it wrong and you have WAY bigger fish.
It’s possible and perhaps likely I will give up and just use their buttons. I’ve spent too much time fussing. Maybe someome far smarter than I will read this and chime in. An example style, and such. Please don’t waste your time.
Again, thank you all for the patience, even if it is thin.
Just do like above and everything will work like you want with my prop. If it doesn’t, then either you didn’t successfully upload or you’re uploading a different config than you think you are
And any (and all frustration) with SaberTrio is not aimed at you or it’s users, it actually because of all of the troubles their users have had (and the countless hours spent trying to help them only to find out SaberTrio created the issue without telling anyone). In talking with them they’ve just said to send ALL of their customers to them for support so we’re kinda stuck. I will say they’ve been trying to help fix things but they’re not quite back to where it needs to be. They don’t seem to understand what makes people want a Proffieboard and what makes a Proffieboard unique and that lack of understanding is leading to constant headaches for users like you. So that’s where my frustration stems from. I’ve spent years making Proffieboard MORE accessible to everyone and they come along and make everything HARDER for their customers without actually telling them “You know that cool Proffieboard stuff you see everywhere and the great community that helps everyone get the most out of their sabers, we’re going to sell you a Proffieboard but ours isn’t going to be able to do any of that unless you jump through a ton of hoops and you can only deal with us directly, no community for you…”
No, not at all. You are spot on. I’m the one who needs to digest and understand what you’re saying.
And that is exactly how I format each style. Exactly as above.
However, I need to use their prop button file, not yours in order for my activation button LED not to flip out. Unless I correctly format each style with the above above mentioned code change.
As for the rest of your posts, they don’t get it. You and I have discussed this.
Memo to Sabertrio: Don’t mess with ProffieOS. Let the experts handle it.
If you want to use my prop AND you want your LED to behave itself just do the above in your presets, if you don’t want to update your presets then using my prop will change the color of your LED, however, you can still technically fix it via Edit Mode or ProffieOS Workbench by just changing the 2nd blade to White again, probably more work than just swapping styles but totally doable as well.
I will give it a go. It’s not that I don’t want to update my presets, it’s that I want to do them correctly. Hence why I need to fully grasp the concept of your style modifications and test accordingly. I’m learning. Getting better, but still learning.
I also had cervical spine surgery a few days ago so I’m catching up on my saber projects, while medicated. Could be part of it. I smell colors.
Might be the medication, there’s not much to grasp.
Currently your presets are telling your LED (2nd blade) to change whenever BASE_COLOR_ARG is changed. You don’t want it to change so just change the style for the LED to only be White and it will stop changing. That’s it, no magic involved
Just skimming through all of this without reading it which I will later. But I think that is the enigma here. He’s got just plain white set for the style but it’s changing, which is what’s defying all logic. And why it would resolve by swapping prop files also makes zero sense.
The config I saw had this set as the second style, which explains it perfectly. When you go from White to Red on a single color LED it will dim considerably and same for the other colors in the Color List.
This is literally what the Proffieboard platform exists to do. The worst thing that happened to the community was LGT palming off their Proffie cores as the cheapest option.
