[PD] Repairing wav files written by pd 64bit
pdman at aproximation.org
Tue Mar 15 05:40:27 CET 2005
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
>>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
>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?
More information about the Pd-list