[PD] soundfiler alternative?

[IOhannes m zmoelnig]

On 2017-02-27 23:50, Roman Haefeli wrote:
> On Mon, 2017-02-27 at 23:13 +0100, IOhannes m zmölnig wrote:
>> 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.
> 
> Thanks for the explanation. Sounds wasteful in my ears.
> 

wasteful of what?

available bits on your RAM module? sure.
code that needs to be maintained? no.

>>>
>>> Seems like there
>>> are still some advantages in use Pd on 32-bit architectures. 
>> which?
> 
> It takes half of the memory to load the same amount of audio files. Or
> did I misunderstand?

no you understood correctly.
but you missed the point, that with 64bit archs you will be able to
address 2^32 times the amount of data you can theoretically address on a
32bit arch.
and while current machines do not have *that* much memory, they still
have enough memory to give you more net-value out of your tables than
32bit machines.

this of course does not apply if you are dealing with legacy hardware or
with embedded devices (including the popular Raspberry Pis), because
they often do not have more memory than can be addressed with 32bit.

> 

gfmsdr
IOhannes


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20170228/d5c70665/attachment.sig>