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-boun...@lists.iem.at> on behalf of zmoel...@iem.at <zmoel...@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
_______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list