I liked Timo's strange actuator patch and re-mapped the FSRs to that instead. It sounds better with the additive synth for the IR sensor, than the [bowedbar~] object did.
It hit me that I was overcomplicating things the way I was differentiating between RGB. If I am just to select whichever one is a higher value, then if I'm only using RGB, then it will tell me which it's sensing. I can't believe I didn't think of that earlier. Maybe because I was already trying to figure out how to get at least one more colour detected, my mind bypassed the obvious and went straight to the more difficult, convoluted method. https://cycling74.com/forums/help-urgent-compare-3-values-and-export-unique-message
This is fine for just detecting RGB, but it gets more complicated when trying to recognize other colours, like orange, yellow, and purple. I went back to the previous example posted in the forums that does a comparison between the colour on the USB camera to colours stored in a coll. https://cycling74.com/forums/max-msp-colour-detection-help-needed
It was when looking at this example that I realized that either the way my data is scaled, or the way the sensor works, colours with red-ish undertones are not as accurately represented in the jitter matrix and [pwindow] than the greens and the blues. This has been going on the whole time, not just with this example. A way around this is to record the values I am getting for all of the actual colours, whatever they may be, then store it in the coll to compare it (rather than using the true colours coming directly from the sensor). For example, when my bright red is detected, it comes off as a purpley/magenta colour in the [pwindow]. I would then take those values, and in the coll label it as red, even though those values are technically not red.
I tried it and with much experimentation I am able to get, red, orange, yellow, green, blue, purple, and off. Although, once I move out from my basement suite in Calgary, "off" will look different because at the moment it has the stored value of my desk colour. I should probably figure out how to make a bottom so that "off" stays consistent.
This coll method was also difficult to do because the more colours I added to the coll, the more likely I got false readings. Also my paint chips have different shades to them, and it was difficult to figure out which was the best shade to sample in order to get the least amount of false readings, and to have the most amount of correct readings for each shade per colour. I found that the lightest shade of each colour, except the orange, worked the best. For the orange, the second lightest shade was the best to sample.
I manually sampled the colours, meaning I connected a message box, put the colour under, disconnected the message box, then added the RGB values to the correlated listing in the coll. Down the road I would like to figure out how to sample colours seamlessly on the fly. But in the coll helpfile I can see that you can add to it with the "insert" message, but it does not replace the existing list; it only adds another line. This may be easier done with just message boxes for each item reference for the sake of flexibility.
Now to add the whole rainbow to my demo patch!