Mathieu Bouchard wrote:

On Thu, 10 Mar 2005, thewade wrote:

...

...

typedef unsigned int uint32; /* long isn\'t 32-bit on amd64 */ I just applied this fix to devel_0_38. I don\'t claim that this is the last such bug. I also don\'t have a K8 so I can\'t test.

Yay, this worked! So now readsf~ works an I imagine that writesf~ does too! (I will test that later) Thank you! Now if arrays would opperate correctly on 64-bit I would be where you all are now, as far as working PD software goes...

Unlike in MAX and jMax, it's not possible make PureData individually address more than 16Mfloats (64Mbytes), because beyond 24-bit the float format loses detail (no odd numbers anymore, etc.) whereas MAX and jMax have a 32-bit signed integer type which can address up to 2Gfloats (8Gbytes).

This issue can be overcome by using 2-D (doubly-indiced) arrays as available in some externals, but nothing that's compatible with regular pd float-arrays, afaik.

If you try to hardcode indices in a patch, and save it and reload it, it's even more limited, something like 20-bit (up to 1Mfloat), after which the values get corrupted.

Im not exacly sure what your are saying here but it sounds like you are trying to explaine the limitations of the current PD array structures to me, a big dummy. I have the worst ammount of knowledge: just barely enough to THINK that I know what is going on.

Anyway I thank you for your attempt but I am hoping if you could translate what you say here to dummy speak.

Lastly I am not worried about trying to use the full addressing power of my 64-bit machine, I just want to be able to use [soundfiler] to write to an array completely (using for example an 8.5 meg file), not just half of an array. I am fine working within limitations. Also is playback from an array using tabread4~ inconstantly responsive because of this 64-bit bug?

Thanks! -thewade e.x.: http://www.aproximation.org/sndarray~.pd http://www.aproximation.org/help-sndarray~.pd