There's a workaround for this - you can put an offset into the right inlet of tabread4~, etc., that allow you to address locally to much better accuracy. For instance, you can give a starting sample as an integer (up to 8 million they're exact) and then address into the neighboring second of sound to a precision of about 1/512 of a sample.
cheers Miller
On Thu, Oct 25, 2018 at 04:15:49PM +0200, Max wrote:
On 25.10.18 09:58, Nicolas Montgermont wrote:
Le 25/10/2018 ?? 09:46, IOhannes m zmoelnig a ??crit??:
the only changes the user might notice when running a 64bit binary of Pd:
- Pd can use 64bit pointers to address memory. that means it could use
about 18.4 exabytes (provided you have a computer equipped with that), instead of a meagre 4GB as is the case with 32bit applications (and Windows would reservere another 512MB, so you could only use 3.5GB)
- Pd can use more features (registerse, instructions) of the CPU,
potentially speeding up the execution (regardless of the number of CPUs)
- Pd can use more modern frameworks provided by the OS. iirc, there are
some ASIO drivers which can only be accessed from 64bit applications.
Does that mean we are now in double precision? like in Katja's benchmark: http://www.katjaas.nl/doubleprecision/doubleprecision.html
Are we still limited by 32 bits pointers to address table? (I dont remember the exact value, I think it was 2^24) that would be reaaaaally nice to manage easily big tables (not so big when you use sounds)
No, 64bit has nothing to do with double precision. Actually IOhannes wrote exactly that in the mail you reply to (in brackets though).
Quote: "it has nothing to do with [...] the precision of numbers within Pd".
I agree that double-precision would be great to have, it doesn't only affect tables, GPS coordinates would be much easier to handle in Pd too. It looks like Pd is slowly going in this direction actually.
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list