On Dec 6, 2007, at 11:43 PM, Mathieu Bouchard wrote: > On Fri, 7 Dec 2007, Roman Haefeli wrote: >> On Fri, 2007-12-07 at 01:26 +0100, IOhannes m zmoelnig wrote: >>> i'll get my wishlist engine running before soon with stuff like: >>> - 64bit-pd (that is, not just run pd on an amd64; but have >>> t_float/t_sample be *large*) >> does that mean, that every float in pd on an 64bit machine will have >> 64bit precision? and each sample in a table uses 8 byte ram? does it >> also mean, that there will be less [tabread4~] floating point >> rounding >> issues (in other words: [tabread4~] sounds 'good' up to x minutes?) > > A day of mono 96000 Hz sound at 64 bits per sample would take 61.8 > gigs of RAM. This takes 33 bits of precision to address. This > leaves 19 bits of between-samples precision for interpolation by > [tabread4]. The precision of float64 is 52 bits, thus the number of > significant bits is 53, still not counting the sign. Thus float64 > completely includes uint53 and int54. This raises the counter > problem's threshold to 9007199254740992. > > And yes, it would use twice more RAM everywhere. This includes the > cache, so it may cause slowdown in some situations. I would enjoy > it if [table] and its friends supported int16 (mere CD quality) for > example. I believe that in float64 mode, pd could benefit from a > float32 option on [table] too. >
I believe IEM has a suite of tools for using 16-bit samples called "iem16". .hc ------------------------------------------------------------------------ ---- Man has survived hitherto because he was too ignorant to know how to realize his wishes. Now that he can realize them, he must either change them, or perish. -William Carlos Williams _______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
