What I mean is that iemgui color format is so complicated and difficult to understand, saying "represents white" is probably the most accurate way to explain how that number maps to a human readable color. On the bright side, this thread has convinced me not to add an animation api in my GUI port. While I think it would serve my own peculiar interests just fine, I really don't understand the implications for more sophisticated use-cases. (And I can easily imagine a user getting stuck because I didn't consider the downsides of my approach.) -Jonathan
On Monday, January 11, 2016 3:08 AM, Roman Haefeli <reduzent@gmail.com> wrote:
On Sun, 2016-01-10 at 22:08 +0000, Jonathan Wilkes wrote:
This limitation is worked-around by reducing the resolution to 6
bits per
channel. The highest number (the one representing white) is -262144.
It does
not exceed 6 digits and can be stored at full precision.
It's probably worth explaining why you say "the one representing white" and not simply "white".
Oh, I'd attribute this to my tendency to sometimes express things too verbosely.
(I.e., what every other sane color format calls "white" does not equal what iemgui's file color format calls -262144.)
I wasn't thinking of that, but you're right. It's not possible to create white (as in #ffffff) iemguis dynamically. If one needs white, one needs to set the color by message. But still when you save it in the patch, it won't be white on the next patch load.
Roman
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list