hi,

I really dont understand the canvas colors message schema

I mean how do I use regular rgb in messages to set the color of a canvas ?

thanks

@phil123456 colours.pd
It is part of a bigger patch, and so non-functional.... but it includes the bit that does what you want......
David.

@whale-av thx dude

wow this is awfully complicated just to change a canvas appearance
besides how come sending a simple [canvas1 color ($1 * 256)+($2 * 65536)+($3... message does not work ?
also I read that rgb was limited in puredata to 6 bits instead of 8

@phil123456 It would work but you can't do the calc in the message. If you just want to change the background you would send the message
[color value( but it needs to be calculated first. You could certainly simplify the patch I posted. If you stick a [print] on the output of [color $1 $2 $3( you will see that it "means" [color back front label( so in fact the color number ($1 being the one you are looking for) is one value (no longer rgb) and although I haven't checked I would guess that it is the decimal equivalent of the standard hex color value........
David.

@whale-av not really the expected color

(the canvas is barely visible cos close to white)

@whale-av

this is the test I made, if it is rgb, they should all be black
it looks more like indexed palette

@whale-av but your code does rgb

Pink as RRGGBB / Hex / 0xCC99CC
Pink as RRGGBB / Integer / 13408716

Magic is (-1 -color) so in that case -1 -13408716 equals -13408717.

Pink color is -13408717.

Note that positive number corresponds to indexed colors.
Note that only the 6 MSB of each RGB component are saved.
Don't ask me why. I have no idea.

Notice that it is not really pink, it is rather violet.

@phil123456 Yes...... in your op you asked how to do it from rgb values!
David.

White (0xffffff) becomes -16777216.
After saved it is transformed to -16579837 that is 0xfcfcfc.
Welcome to PureData where everything that should be simple is wonderfully complex.

@whale-av yes, I meant from your last reply, never mind
I see now from your explanation, that MSB got to be set (neg numbers)

this is rather sick, I mean if at least it was explained somewhere in the FLOSS manual, jesus

@Jojo-Lapin tell me about it

...

R is 204 / G is 153 / B is 204

i = B + (G * 256) + (R * 256 * 256)
i = 204 + (153 * 256) + (204 * 256 * 256)

color = -1 -i
color = -1 -13408716

color is -13408717

@Jojo-Lapin It is pretty simple really...... its just that computers prefer hex......
David.

You need to pack 3 integers in a unique float (cross your fingers and later scratch your head to think about floating point precision) with bitwise operations and then negate it (instead of ((("- Why?"))) just provide those three arguments). And later that number is altered just by saving it to a file. It is NOT simple.

@Jojo-Lapin well so far I am lucky I dont need to save these values

I think perhaps one of the problems expressed here (though I'm not sure which one!) has to do with the dual-precision internal processing vs. single-precision external save/retrieve limitation present in all versions of Pd, with the exception (I assume, haven't tried it yet) of the experimental dual-precision build that was produced some time ago.

I unexpectedly ran into the issue myself when trying to set up dynamic color programming of the GUI objects after making a whole panel of them using the preset colors from the preferences panel. I noticed immediately that most of the 0-29 preset color numbers that I sent with messages obviously didn't quite match the 30 presets available in the panel grid. So I tried grabbing the RGB values instead by plugging them into the "pd RGB" calculator that's part of the GUI color edit help patch. Those wouldn't save properly. I must assume at this point that it's because those panel colors are all linked internally in Pd to the 6 digit hex value you can see in the "compose color" RGB pop-up panel. Many of those hex values translate to dual-precision decimal numbers, (which can't be saved without the app rounding them off) and on the external user-programmable level Pd only works with decimals, not hex.

What it comes down to is that although you can enter or generate dual-precision decimal values in realtime (like with "pd RGB"). You can't save/retrieve them without the numbers getting rounded.

My workaround to match the panel presets was to just fudge the single-precision decimals till I got it "close enough". The only other workaround I can think of to get it exactly right is to save the three RGB numbers as a list and then feed them with [unpack] to the pd RGB calc and embed the whole blob into the patch every time I wanted to switch some colors.

The various Pd sites and lists have a number of write-ups about the dual/single precision issues. There's also some stuff on the list somewhere about the 2 different sets of preset colors (I think the remote-switchable preset values all translate to single precision dec values, not sure). Don't have any links on hand ATM but the info can be found in many bits and pieces (like most of the info on this platform) if anyone is more interested in this topic.

I found the post i read recently about the color scheme on the Pd-dev list.

< https://lists.puredata.info/pipermail/pd-dev/2016-01/020535.html >

@Jojo-Lapin Thanks, that link sums it up rather well.

Edit: Upon re-reading that link, It would seem that even the extended dec values don't represent the true 24-bit colors but are a "crunched" format to try to get as close as they could with the single-precision limitations. No wonder nobody understands it!

To save the iem colors two bits of each component are scratched.

RRRRRRRRGGGGGGGGBBBBBBBB
RRRRRR__GGGGGG__BBBBBB__
RRRRRRGGGGGGBBBBBB

The 8 bits per component is compressed to 6 bits per component. It is expanded at load in the opposite side.

You lose 2 bits of precision (i.e 255 becomes 252)