Dear José Thanks for the hint. I was indeed aware of this library and would also use it if I'd hit a memory limit and would be dealing with sound files. It seems like purpose is to allow to store specifically sound more efficiently, no so much arbitrary byte-level data (though one could easily write an abstraction to store 2 bytes at one table16 index.
I was just curious to think about it since we have now a general way to deal with files on a byte level, I wondered if there is a similarly general way to deal with bytes in memory. Obviously, there are arrays, though they eat away 8 times more than strictly necessary on today's systems. I'll stick to them anyway. Roman On Thu, 2022-01-13 at 11:41 -0300, José de Abreu wrote: > Roman, maybe you could use iem16? > > https://git.iem.at/pd/iem16 says that it is "16bit storage for Pd" > > looking at the helpfile of [table16] we read: > > "[table16] stores 16bit values. The normal pd-tables ([table], array) > store the values as floating-points. While floating points are > (often) more precise (this is of course not really true..., esp. when > comparing integer(4byte) to floating-point.) they use a lot of memory > (4byte). > > [table16] uses only 16bit (2bytes) to store the values, which is half > of the memory." > > So maybe it is exactly what you need? > > Em qua., 12 de jan. de 2022 às 11:57, Christof Ressi < > [email protected]> escreveu: > > > I read > > > once in IRC that one value in a Pd-array requires not 4 bytes, > > but 8 > > > bytes on 64-bit systems. > > Yes. Pd's graphical arrays (and Pd's data structure arrays in > > general) > > are implemented as a linear array of "words" (t_word). A "word" can > > hold > > one of several possible types. It is implemented as a C union, so > > the > > overall size is always that of the largest member. In our case, > > the > > largest member is a pointer (e.g. t_symbol *), which is 4 bytes on > > a > > 32-bit system and 8 bytes on a 64-bit systems. > > > > This means that even if you would add a "byte" type, the overall > > size of > > "t_word" would stay the same. > > > > However, you can always implement your own byte array object as an > > external. But as you noted, this is not necessary except you're on > > a > > very tight memory and/or CPU budget. > > > > Christof > > > > On 12.01.2022 14:20, Roman Haefeli wrote: > > > Hi > > > > > > Sometimes I stored byte data (lists of bytes) in arrays. IIRC, I > > read > > > once in IRC that one value in a Pd-array requires not 4 bytes, > > but 8 > > > bytes on 64-bit systems. Since storing plain bytes seems not such > > an > > > uncommon use case for me, I wonder if it can be done more > > efficiently. > > > Not that I ever hit a memory limit, I'm just curious. With the > > new > > > (amazing!) [file] object, dealing with byte lists has become even > > more > > > appealing, so the desire to store them in memory increases. > > > > > > > > > Roman > > > > > > > > > > > > _______________________________________________ > > > [email protected] mailing list > > > UNSUBSCRIBE and account-management -> > > https://lists.puredata.info/listinfo/pd-list > > > > > > > > _______________________________________________ > > [email protected] mailing list > > UNSUBSCRIBE and account-management -> > > https://lists.puredata.info/listinfo/pd-list > > _______________________________________________ > [email protected] mailing list > UNSUBSCRIBE and account-management -> > https://lists.puredata.info/listinfo/pd-list
signature.asc
Description: This is a digitally signed message part
_______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
