On Mon, 2017-02-27 at 21:10 +0100, zmoel...@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
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
