I looked at d_soundfile.c briefly and didnt see anything in the 1 min scan, but I have to go and cant really get into it today. I was hoping that someone more fimiliar with that file will immediately recognize the problem. Otherwise I will look at it tonight hopefully.
I am looking at both pd-0.38-4 and devel_0_38, and I see something to fix in d_soundfile.c. Change the definition of uint32 so that it's really 32 bits:
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...
Thanks again! -thewade
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.
Mathieu Bouchard -=- Montréal QC Canada -=- http://artengine.ca/matju
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).
are you sure about 8GB? afaik the size limit to .wav is 2GB. thats why wav64 was introduced..
i dont suppose someone has a sox oneliner to recursively convert subdirs containing .w64 files into something pd can read? just realized how many of these files have accumulated, what with timemachine using it as the default format..
On Sat, 12 Mar 2005, scythe wrote:
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).
are you sure about 8GB? afaik the size limit to .wav is 2GB. thats why wav64 was introduced..
Arrays are not bound to the .wav format. Writing to .wav will fail at whatever the size limit of .wav is. However you can also create arrays that you never save.
Mathieu Bouchard -=- Montréal QC Canada -=- http://artengine.ca/matju
-
Mathieu Bouchard -
scythe -
thewade