[PD] soundfiler alternative?

Roman Haefeli reduzent at gmail.com
Mon Feb 27 23:04:06 CET 2017


On Mon, 2017-02-27 at 21:10 +0100, zmoelnig at iem.at wrote:
> On 02/27/2017 07:06 PM, José Rafael Subía Valdez wrote:
> > 
> > Thank you Lucas and Ingo,
> > 
> > well. I do need to load a lot of samples if I want them preloaded.
> > Regarding the ram post that you sent, as I understand, that is
> > exactly what
> > table does, as it stores it in RAM (am I right?)
> 
> 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. Seems like there
are still some advantages in use Pd on 32-bit architectures. 

> > Ingo, if I understand correclty, I need to record the audio from
> > readsf~
> > into a table. this means that I need to create the record system to
> > avoid
> > clicks (fades in and out). This seams overcomplicated for a simple
> > thing.
> > But it appears to be the only solution for this problem.
> > 
> it is not such a simple thing if you care for deterministic
> sample-synchronous playback (you personally might not care, but Pd
> does).
> however, there is a simple solution at hand: get youself plenty of
> RAM
> and pre-load everything into tables.
> 32GB cost about 250,-€ and will allow you to load approx. 24h of raw
> audio, which is probably enough.
> it's not exactly super-cheap, but writing software isn't either.

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.

Roman
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: This is a digitally signed message part
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20170227/c67905c8/attachment.sig>


More information about the Pd-list mailing list