We need a more clear explanation of how to use this tool. about msi-rgb HOT 13 OPEN

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.

from msi-rgb.

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:

transposed:

Documentation would be much appreciated. If you need help figuring anything out, ping me and we'll figure it out!

from msi-rgb.

Okay. Good to know.

If you need help figuring anything out, ping me and we'll figure it out!

Will do! Thank You!

from msi-rgb.

We can open a pull request if we need it 🐎

from msi-rgb.

@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.

from msi-rgb.

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?

from msi-rgb.

from msi-rgb.

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).

from msi-rgb.

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.

from msi-rgb.

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.

from msi-rgb.

So do you have a demo of that?

from 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.

from msi-rgb.

Things get weird this close to the metal. Esp. when the metal is an undocumented proprietary SIO chip.

from msi-rgb.