Just because we are at it.
On w32 I can have long tables but I cant get values beyond 16777216 using [tabread].
Also a simple counter stops there, printing with [makefilename %d]:
print: symbol 16777213 print: symbol 16777214 print: symbol 16777215 print: symbol 16777216 print: symbol 16777216 print: symbol 16777216 print: symbol 16777216 print: symbol 16777216
Is this also happening on 64bit Pd/OS?
Mensaje telepatico asistido por maquinas.
From: Pd-list pd-list-bounces@lists.iem.at on behalf of IOhannes m zmölnig zmoelnig@iem.at Sent: Monday, February 27, 2017 10:13 PM To: pd-list@lists.iem.at Subject: Re: [PD] soundfiler alternative?
On 02/27/2017 11:04 PM, Roman Haefeli wrote:
well, [table] stores the samples as floating point (taking 4 bytes per sample; and 8 byte on 64bit systems)
Why is that? And why does it only apply to arrays and not to all other number types in Pd? I rather curious than sceptical.
Pd's tables use a unified design, that can store all kind of things, including numbers and data structures. since data-structures are stored by reference, a data element in the table must be able to hold a (void*) pointer, which - on 64bit systems - takes 8 bytes. the actual numbers stored in these fields are still only single precision numbers.
Seems like there are still some advantages in use Pd on 32-bit architectures.
which?
Unfortunately, dealing with largish tables has its complications two which I thought is exactly because everything is stored as 32bit float, even on 64bit systems.
well, this depends on what you actually do with the tables. afaiu, the OP was happy with the using tables, only the data-loading was causing dropouts. so the problems with data precision do not apply here.
fgmdasr IOhannes