Thanks for the reply.

Yes, at the moment, I'm using 0.42.5 Lucid 64bits. I just tried to install the 0.43.5 Lucid 64 DEB with no luck.

I think I should compile... The only soft I compile in my life is Blender from SVN. I don't think compiling PD would be difficult... but I don't find a step-by-step tutorial to do it. Do you know any?

From

http://pure-data.git.sourceforge.net/git/gitweb.cgi?p=pure-data/pd-extended...., I can get the branch... but it's only 2MB. Where are the externals... or all the other data?

El 03/07/11 12:59, John Harrison escribió:

I used 64 bit from lucid on my natty machine. I think I had to use gem from the repos but otherwise it works fine.

Sent from my cell...

On Jul 3, 2011 10:57 AM, "Mario Mey" <mariomey@gmail.com mailto:mariomey@gmail.com> wrote:

...

Hello, everybody. Is there any build for Natty AMD64 of the Extended version? For the moment, I don't want to compile it...

Thanks!

---

Pd-list@iem.at mailto:Pd-list@iem.at mailing list UNSUBSCRIBE and account-management ->

http://lists.puredata.info/listinfo/pd-list

Hi

We were talking about this particular topic some days, ago, you should have searched :) I did compile pd extended for natty 64, but it's lacking some libs due to my lack of compiling skills, so my build does not include pdp, pidip, gem2pdp, pdp_opengl.

#LIB_TARGETS += hid pdp pidip gem2pdp iem16 pdp_opengl postlude LIB_TARGETS += hid iem16 postlude

Just tell me and ill upload it somewhere.

On 03/07/2011 17:56, Mario Mey wrote:

Hello, everybody. Is there any build for Natty AMD64 of the Extended version? For the moment, I don't want to compile it...

Thanks!

---

Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list

Hi Mathieu.

On Sun, Jul 03, 2011 at 01:36:50PM -0400, Mathieu Bouchard wrote:

On Sun, 3 Jul 2011, Chris McCormick wrote:

...

Despite reading several posts in the archive and the source code in
g_all_guis.c I am embarrassed to say that I am completely stumped by the problem of extracting the individual RGB components from the IEM saved color value in the .pd file, as ints between 0 and 255.

as a reference, [#to_iem] supports both iem colour formats, the 18-bit
format for files, and the 24-bit format for messages. Such a patch is very simple :

http://gridflow.ca/svn/trunk/abstractions/%23to_iem.pd http://gridflow.ca/help/%23to_iem-help.html

But it does the opposite conversion of what you are trying to do.

Thanks for the tip. I did have a look at [#to_iem] as well but all examples and documentation on this topic seems to be around converting to IEM numbers as you point out.

...

What I am doing (in the case where the saved value is negative) is: iemcolor = -1 - iemcolor; r = (iemcolor & 0x3f000) >> 14; g = (iemcolor & 0xfc0) >> 4; b = (iemcolor & 0x3f) << 2;

this is the 18 bit iem format that you are trying to convert to a 3*8 bit component format. You are correctly extracting blue and green, where the
shift is 0*6-2 for blue, 1*6-2 for green, but it has to be 2*6-2 for red.

For the 24 bit iem format, instead, you have to shift by 0*8, 1*8, 2*8.

-2 is the difference between 6 bits per component and 8 bits per
component.

Note that those conversions scale in a crude way, such that 63 is scaled
to 252, instead of the maximum 255. If you want to scale more
appropriately to fill the whole range, you need to post-process those
components a little bit(s) :

r = r | (r>>6) g = g | (g>>6) b = b | (b>>6)

Ah, this is great. Thanks for this information! One last thing I am confused about is how I can tell the difference between the 18 bit iem format and the 24 bit format? In g_all_guis.c I can only see a check for positive/negative numbers. Also, what is the iemgui_modulo_color() function all about? I have implemented it for consistency but I don't understand why it is there.

Thanks for your help.

Cheers,

Chris.

http://mccormick.cx