Best is to have all soundfiles preloaded.
RAM-Disk will help if the soundfiles are short. (this skips the “seek time” of a real hard disk)
Even without RAM-disk this is related to your actual Audio-settings “delay ms” : more delay more large files without audio drops.
Don't know exactly what your patch is about.
Mensaje telepatico asistido por maquinas.
From: Pd-list pd-list-bounces@lists.iem.at on behalf of zmoelnig@iem.at zmoelnig@iem.at Sent: Monday, February 27, 2017 8:10 PM To: pd-list@lists.iem.at Subject: Re: [PD] soundfiler alternative?
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), whereas most soundfiles will use less bytes. so having them on a RAM-disk, could indeed help.
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.
gfmdsar IOhannes