msi-rgb
msi-rgb copied to clipboard
nagisa
We need a more clear explanation of how to use this tool.
I've been messing around with this for a few days now and I can tell its a powerful tool. Well done to everyone involved. However Its extremely difficult to figure out. I'm good enough with the terminal that I can hold my own but I'd like a more detailed set of instructions. The <Red> <Green> <Blue> arguments particularly confuse me. I've worked with color before (a little bit of web stuff) but this seems off. I'd really like a document with a bunch of examples on how to use this.
I'd be happy to write this myself but I'm going to need some help mastering the use of this program to begin with. I understand everyone here is volunteering and we all have other, perhaps more demanding, things to handle.
For now I'm going to keep messing around with this program. Once I feel confident using it I'll write out a doc or something to help new users. In the mean time if anyone more confidant with this wants to help me out go ahead. I just need a little explanation.
The problem with this tool’s interface is that it exposes the hardware with least amount of sugar on top of it as possible. That means that the colour specifiers, for example, do not exactly specify a single colour, but rather four of them.
So something like
.../msi-rgb AABBCCDD 00112233 44556677
ends up showing colours #AA0044, #BB1155, #CC2266 and #DD3377 in sequence: i.e. the colour matrix is transposed. It is easy to see if written as a table:
| 1 | 2 | 3 | 4 | |
|---|---|---|---|---|
| R | AA | BB | CC | DD |
| G | 00 | 11 | 22 | 33 |
| B | 44 | 55 | 66 | 77 |
transposed:
| R | G | B | ||
|---|---|---|---|---|
| 1 | AA | 00 | 44 | #aa0044 |
| 2 | BB | 11 | 55 | #bb1155 |
| 3 | CC | 22 | 66 | #cc2266 |
| 4 | DD | 33 | 77 | #dd3377 |
Documentation would be much appreciated. If you need help figuring anything out, ping me and we'll figure it out!
Okay. Good to know.
If you need help figuring anything out, ping me and we'll figure it out!
Will do! Thank You!
@Nagisa I notice you are using symmetric tweening values in your example eg. AA BB CC DD 00 11 22 33, etc.
The SIO chip uses reverse endianity, so symmetric values always give the right tweening, but limits the number of tweens to 4 instead of 8. To set tweens in correct order, use little endian notation.
Eg. A0 ==> 0A 13 ==> 31 02 ==> 20
Note that these values are per RGB channel, so they represent brightness of the channel at a given tweening step (of which there are 8, one of 16 possible levels per step).
Also as an aside, I was able to double the colour depth by including half refresh rates which doubles the colour depth without any flicker. This gives much smoother fades and transitions (the default is rather crude and aliased).
I shall submit a pull request with the improved color mapping algorithm at some point.
What do you mean by "limits the number of colors to symmetric values"? Isn't the range the same - from 0x00 to 0xFF? Even if it were setting the wrong colour, 0xA0 yields a very different colour from 0x0A. Wouldn't it be obvious that it was wrong?
I believe it’s not limited to symmetric values. It’s my understanding that symmetric values just make better examples for explaining how the program works.
I could be wrong. I’m on mobile using email at the moment so I can’t read the context of this thread right now.
I’d just like to ad that I am still working on writing documentation. I haven’t had much time recently but I want to clarify that I haven’t forgotten.
On Jan 19, 2019, at 7:59 PM, Pedro Fanha [email protected] wrote:
What do you mean by "limits the number of colors to symmetric values"? Isn't the range the same - from 0x00 to 0xFF? Even if it were setting the wrong colour, 0xA0 yields a very different colour from 0x0A. Wouldn't it be obvious that it was wrong?
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.
The context is that the reversed endianity issue is not mentioned in the docs, and is obvious to anyone that has actually tried to get specific tweening out of msi-rgb.
It should be modified to allow big-endian values to be passed rather than forcing users to pass little-endian (reversed) values. Obviously symmetrical values (00, 11, 22 .. FF) are exempt from this issue. At least the help output should mention this.
BTW all x86-based operating systems are little-endian. This boundary issue regularly bit me back when I developed on Sunmicro's Solaris (previous SPARC CPUs were big-endian; don't know what Fujitsu plans to do in upcoming generations).
Works fine here. Byte order is not the issue. Do note that there are 8 different colours, not 4. Each nibble is a different colour.
The four byte value for each colour channel (RGB) represents 8 tweening steps (one of 16 levels of brightness possible at each step).
You are getting the wrong tweening if you don't reverse the endianity. That means switching the nibble order of individual bytes (2F --> F2), not the bit order.
So a smooth fade to black on a given channel: FC A8 42 10 becomes: CF 8A 24 01
Without this your fades will look aliased (glitchy - not smooth).
It is a fine point and easy to miss, but my OCD would not rest until I figured this out.
You can try the above values yourself to verify the tweening requires little endian notation
eg. compare:
msi-rgb FCA84210 FCA84210 FCA84210 Aliased glitchy fade.
to:
msi-rgb CF8A2401 CF8A2401 CF8A2401 Perfectly smooth fade!
And the OP was very correct this is NOT in the docs, and yet is essential to designing effects properly with msi-rgb.
That's... interesting. I actually had seen the pattern and had documented it but genuinely thought someone just decided to use weird patterns.
Things get weird this close to the metal. Esp. when the metal is an undocumented proprietary SIO chip.