umm...not sure if anyone's made a simple external to do that yet, but i'll tell you the way i was doing it:

*first, give up on sfplay~ ...you wanna write your audio files into arrays, and then use tabplay~

*the way in which i was "timestretching" was a bit weird, and the effect was a bit different to a normal timestretch, but it worked nonetheless....

what i did was to get the sample length in bytes from the output of the [soundfiler] object, and then divide that by 32 to give the lentgh of 1/32 part of the sample

tabplay~ can be triggered with byte offsets, so i used a metro and simple counter to increase the byte offset by 1/32 of a sample every click, and then return to zero after 32 clicks.

this worked really well for timestrethcing down, and sometimes worked ok for timestretching up, but it could get a bit stuttery.

recently though, i've been really getting into just changing the pitch to keep things looping. not sure why, it just sounds better to my ears when things get pitched funny.

not really a useful reply, but i'm having the same difficulties. I'm guessing that something in the source code specifically is written for the 32 architecture. For instance on a 32 bit machine integers and floats are a specific size but in a 64 bit machine that size is different. Perhaps Puckette has some variables that are created on a low level so that he has specified the size to be that which is normally used in a 32 bit environment.

Hopefully when (if) I get the time i can take a look at the source code and see if I can find anything out. A cursory look at x_gui.c says that the line in quesiton reads "sprintf(buf, "d%x", (t_int)x);" . sprintf is this buffer writting mechanism...here he is writting something into the buffer and converting it to his own type (t_int), through explicit type casting, in the process.

He defines t_int in m_pd.h where he takes care of making sure all the precompiler junk is squared away.
"#ifdef __alpha__
typedef long t_int;
#else
typedef int t_int;
#endif"

Perhaps someone with experience in multiple architectures could help...or perhaps someone wants to bug a pd-extended developer or even Puckette himself.

My guess at a solution is to get the compiler to use a 32 bit word ("word" is the term for the size a variable takes up) and not a 64 bit word for all variables. (not quite sure if this is really possible though). You might also try compiling it on a 32 bit machine and copying the whole pd directory over to your 64 and giving that a shot.

Also you may want to change the makefile so that it points entirely to ../libs64/ or entirely to ../libs/