On Mon, 2017-02-27 at 21:10 +0100, zmoelnig@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