My aim is to load multiple soundfiles in a patch, and access them separately
For now i’m using polybuffer~, but since i don’t really need to process the audio, just straightforwardly read, i was thinking, why not use sfread~ and cues ? maybe i would gain some RAM ! which are things i don’t know anything about.
So now, back to the topic : i saw that, in the sflist~ object, you can specify a buffer size. Ah. I thought sfplay~ was reading direct from disk ? So what is that buffer for ? Does using cues mean that you need to preload all the sound defined by the cue in a buffer, or is it like a buffer for loading just right before reading, which is emptied while accessed, like some streaming ?
I ask this because, in the case where each preloaded cue means that the soundfile contained in the cue is integrally loaded in a buffer, there is no memory gain compared to using polybuffer~, then i’ll stick to polybuffer~. If not, then "cues" would be the way to go, wouldn’t it ?
When playing from a hard drive, sfplay~ reads datas from the disk into a buffer (in RAM), and the buffer is used to produce the MSP signal. This is because reading a hard drive is slower than reading RAM. When preloading a file or defining a cue, the idea is to read the beginning of the sound into the buffer to make sure it will start asap when you want to play it. So the buffer doesn’t contain all the sound file, but just a small part, its size depending on the parameter of sfplay~ you defined (or sflist~, which just provides an easy way to manage cues).
Patrick is right. The sfplay~ object reads sound files from disk, but it buffers a small amount in advance to avoid getting behind. The ‘open’ and ‘preload’ messages open the file and preload a bit of sound into the buffer so as to be ready to play. But the amount stored in RAM by sfplay~ is very small (tens of kilobytes) compared to loading an entire file into memory with buffer~. You can read about it in the "buffer_size" tab of the sfplay~ help file.