Colour non-sense...

[ustk]

There's a strange thing happening with the colour when used as HEX vs computed.

For instance I have this THEME colour 0xfffb3984, from which I obtain the HIGHLIGHT colour 0xFFFF85B4 after applying some saturation and brightness (using Hise stock methods)
I can confirm the HEX obtained using a colorPicker on a panel I painted with.

briefly:

const var THEME     = 0xfffb3984;
const var HIGHLIGHT = getColourFromTheme(0.48,  1.0); // sat + bright -> 0xFFFF85B4

But from here it makes no sense:

• If I use the variable in a paint routine as HIGHLIGHT, no problemo, it's the good one.

• Now if I programmatically set a colour property of some components using HIGHLIGHT, essentially the preset browser floating tile, the resulting colour displayed is absolutely different (like green instead of pink)
  While pasting directly the HEX equivalent works... (even if both methods show the same HEX in the property panel)

But this is not the case for other components like labels, for which if you either set the colour programmatically with the variable HIGHLIGHT or paste the HEX value, the result is the same, as expected

Ok... So the preset floating tile colour handling is broken and then what?

Well this is where things get interesting.
When printing the decimal equivalent, you get two different values despite a colourPicker giving the same HEX for both:

Console.print(0xFFFF85B4);  // 4294935988
Console.print(HIGHLIGHT);  // -31308

So my guess is that in the components that are working with either values (aka property set manually vs programatically), it might be because of some sanitisation behind the scene. While in the preset browser this sanitisation might simply not occur, so -31308 returns hise green instead of pink.

So the questions are:

• Why are the decimal results different, while a colour picker shows the exact same HEX? Are those decimals equivalent like when you make a full revolution around a trigonometric circle? (like 3 PI being equivalent to PI)
• Why, if a sanitisation is needed, it doesn't happen directly after the use of Colours.withSaturation() and Colours.withBrightness()?
• Can we fix the preset browser floating tile colour handling?

[ustk]

A little snippet to support the case...

HiseSnippet 1638.3ocuXssbaTCFVqa1RsoGnyvCfFeCNfw01woMjRo1NwowCwIlXmRY5zoHuq1XMYsjGsZyA5jY3FtmmCtlmEtlGAtiKK+Z20dWeJMwLvNSRpz+oO8eTpskBKpmmPhLxz8hgTjwcM6bAW0eq9DFG0bajwmXtkvU3K2Wv6P4dTT8KFR77n1HCia8BMWFoWAE78WOuNwkvsnwagPuTvrn6wFvTw61t52xbc2gXS6xFjf6JUaZI3g1CYbKyhngDqSHGS2mnYKkIZWhWejwmaVlXuQE60KYUpXEh0ZOd8x8V2ojCkTobwxq8jxkbpPsrKQPF2tgMSIjcTDE0CTZcg8Ec5KNiGZfWx7X8bo5EkPc.KGtMZq9LW61ibOdHjwJsicV2JzY8olsX1rw6mzooIfikHoSyH0UAoR2.HYj.RqDBoGZ1wRxFphonwyGa1jqnRGh0jwuPdQodqIDkAN3pBCHmP2QBKFKQtGWrXdL7qUeZFfKOgKsfkKkHyAajICDw7T3SIRb2cazpAV+8Lbwycbb5s1WsQkmlfica9hc2C9oKvwwTUXjFr1ft8oCn4JVnxF4w3RE.SgezivdDE9Kv8jri6qve42.JcG3ai0qWAraFfgY0QFF2kwoXGetkhI3yyLfZ8kDM07QJmCtpUy7tLocEVD2.69LbnXdENio52YrH4BNk4wwJA7BQxYIbmRt5iUu1pSXNPpLokTPKbsfOMykgmosarUyV01C236Np4KqsWi861AW6vFEJTXr2enjwU4xtaiWUKh6MwYAOUr+AzNnJPl8OnaBMMsF15fVsOpais2TGzzZHNBEDaSD55o3dvg60ixSB7qCFJ3Tshp6qTBdorqlOCdluqRjxYW8MZKMcXSv0FTKoT3lyZjX4Ar35SChULGbtnUogkQw.eO5tzyAjpku.iaSO+.mXErJ9YPxI36Ame54Cr8H8ntvQIB8E7nvlJ54Q4QYgLzHi77Ddb7lI8c5r2yDxS7VnUZS3yZElhN3+SqTFLyGzJKT463JfB.9wcYtTvFK8QvVP83elJ3njI8kYtDRHbDRbtdXFOHNtJtmV6QoCaQbc6ACFxMQRB.zDYO6KTzC34BRTfJK7zjbblKsHc4Rkykrdbk7pDLG2ePOpLYZplQn87j87u80qmuUneOAiBdSNScvPZz5cDt15d45+8rSHPQANXVQpHDBrpBlTb+nIEg0gHFnjzlQ0wn.3mbxN5FHd4oEG9Np41DEQOyJBR.LGRkJl1aXrM8T3VBgSvRatM06DkXHxvbbxFLBKzr2KxrAEoAV8NlgErnyiM3OT8hwK9YmpmwrUv0FLM9UCDpOU2BVupLP0APSG1Ok.raTkBgJRPz.NrPcOx3iBsAp2witbR5aCr9dM+wcFz696+x6C1Ek.52YRnGTSFA8v5yEA8pCWDz+ZfZbkVRCmn3dQ34tpnauDhmjkwAv5AlSTYm.cUSht+zuZTrLLv8.y1RJTkVWJNyiJm1Y82nqKlGkyDjwj5ORY9NXnRVcQPGxozvbrrahUReZ9QTZb9PB2CpE8pAMDb8Gn4vg35EyRPohb9hq6I3MiNg7fP1mfT71PWD37BzJUbrP0rsmuINjxgawNeZaScopEPqCbSKq90IxjD1gbpPBtM88kGihXPjj7Dh4651ln5Oht2DNonyZSvOZSqKjf2ZB566OHz0pEasfsBW+85jzC0WFBH75fa.TrvZS8k+FtOr8aBrwdLOUMIkL9bFYg7y6OikJDYGJNqMw1FRkutxM1cWW3ys0mzWGRnkPFEgllRbV4zTF4mmgZlKQKnx92lokx3dnIJgSeM5gmnrklnrE0sZXSszlG0oAFtDIBxLg1c5mrrGb5459dRhMS7BoveX3rkwn8bTRzl6FiqxIv0O5MObc+.bM5po+aA2rOQBdblv12knl7Ea52xFQ.ZiLwyjzOEBJJTWjbh3M3YbEuxmwccg3CMayTV8mOFSMGLpm5+e.Fid768La33PsTw.bEycd0x9R2Of4OT3qmG0hnjLH+wDZE0AJOrnf04vHTOc7NkNWLbcQ8ZsGnCkaGr38vWDwR50FQDKMhHZ.wRJdqU38bzOu9NA6.XhG7e+PZyV503Ryd8lAP14asrlTUyHX4kUv0VVAqrrBt9xJ3iWVAexxJ3FeXA0MOp4qDCBKaPnVsaDb4BCiFAcWBxVQ+CvssBkB

[dannytaurus]

@ustk Seems that when you set a colour variable it's stored as unsigned 32-bit but the return of the calculation is signed 32-bit.

They are the same number, but different formats. It looks like the floating tile doesn't like the signed format and falls back to the default green colour.

If you force the calculation result to unsigned, it works as expected:

inline function getColourFromTheme(saturation, brightness)
{
	local sat = Colours.withSaturation(THEME, saturation);
	local col = Colours.withBrightness(sat, brightness);
	//return col;
	// force unsigned 32-bit result
	return col < 0 ? col + 4294967296 : col;
}

Not sure if that's considered a bug, or just another gotcha we have to remember and accommodate.

[dannytaurus]

@ustk Full disclosure, I figured this out using ChatGPT

[ustk]

@dannytaurus Oh cool! Bug or not I can at least make my project to work so thanks!