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 <[email protected]>
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
_______________________________________________
[email protected] mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
_______________________________________________
[email protected] mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
