[PD] soundfiler alternative?

[Lucas Cordiviola]

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 at lists.iem.at> on behalf of zmoelnig at iem.at <zmoelnig at iem.at>
Sent: Monday, February 27, 2017 8:10 PM
To: pd-list at 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



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20170227/e8ee271a/attachment.html>