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-boun...@lists.iem.at> on behalf of IOhannes m zmölnig <zmoel...@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
_______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
