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