Okay, I'll try re-phrasing this...

Given a short sample: samp_144k.wav (a sample 144k in size)

Will a play~/groove~ + buffer~ sized to the sample (144k -> ms @ sr), play back samp_144k.wav in essentially the same way as an sfplay~ with a disk buffer of 144k? That is, are play~/groove~ + buffer~ any more efficient internally to MSP than sfplay~ + disk buffer?

My dilemma is that either I'll be doing a lot of reading to buffer~ objects and playing from groove~ during playback, or I'll be preloading a bunch of samples (with a large disk buffer setting) to sflist~ and playing them back from sfplay~ during playback. Both will be disk intensive. It seems to me that sflist~ will be easier on the system for preloading, on average, because it's only ever loading the disk buffer, whereas buffer~ must load all of the sample data to be played. Because the disk buffer is always the same size, the work load should remain roughly consistent when using sfplay~, whereas with buffer~, the disk activity will spike each time a new sample needs to be buffered. Is this clear thinking? So, given that the disk activity will be high either way, which is really the better option?

J.

This is a very relevant question, but I cannot supply the answer. During some preparations for a class I was giving, I made a 12-voice sampler using sfplay instead of my normal buffer-based techniques. I could not hear any extra latency nor observe any disk-use problems, but I didn't spend much time searching for them, either.

This sort of sampler has some obvious advantages over a buffer scheme, particularly when it comes to larger installations or a great amount of sound material. One problem which I can imagine is interuptions in smooth disk-use when the OS needs to do something else.

So: who has the real information?

Woohoo!!! A reply!!!

Obviously, I'm with you on the importance of this question. I'm embarking on a massive re-write of a patch I made, and I'm seriously considering the sfplay~ route. I'm glad to hear you had a decent experience with it. Personally, I can't see any great reasons why it would be a problem, other than what you mention about HD activity level -- though you add an important point in mentioning system-related/background HD access.

However, in my situation I'm just looking for the "lesser of two evils", since with constant reloading/resizing of buffer~s I'm still at the mercy of the HD. (And besides, there is no great way around system priorities, short of renicing the app (or Max), which actually appears to do very little, in my experience.) So, on an semi-educated-guess level, I don't see any major problems with going for sfplay~... but it would be nice to get the "official" position, in case there's some evil lurking behind sfplay~'s innocent exterior.

Anyway, thanks for the support. Hopefully we'll see a little more action on this question now!

cheers,

J.

jbmaxwell wrote: > Will a play~/groove~ + buffer~ sized to the sample (144k -> ms @ sr), > play back samp_144k.wav in essentially the same way as an sfplay~ > with a disk buffer of 144k? That is, are play~/groove~ + buffer~ any > more efficient internally to MSP than sfplay~ + disk buffer?

It depends how often you play the same material. If you play everything only once, then I would assume that the sfplay~ method is more effective.

When the Giga Sampler arrived at the market there was a memory problem. They wanted to play a piano sound which could not fit into memory of that time. Times have changed.

As sampler usually wants to play a sample more than once, if you load it into memory you can play it as often you want, but need to load it only once at initialisation time.

I can easily fit hours worth of samples into the memory, If you still would not likely play any of these sounds twice, then sfplay~ is certainly more efficient. But even if you only partially reuse samples, then you hit the disk less frequent with buffers.

If you have a lot of samples cues, which you want to load from disk, you also need a lot of memory. That means as soon your samples are shorter than the sfplay~ diskbuffer size of 20160 bytes, you will need more memory than with filling buffers.

These are logical assumptions... To proove them, you should test it. You can run tests by placing your abstractions into a poly~, then just increase the number of voices till it will hit your limits.

Share the results...

good luck

Stefan

--

[][] [][][] [][] [][][] [][][][][][][][][][][][][][][]

Stefan Tiedje Klanggestalter Electronic Composition & Improvisation

/~~~~~ \ /|() ()| ))))) )| | |( \ /// _/)/ ))))) ___/ ///

-------------------------x---- --_____-----------|----------- --(_|_ ----|-----|-----()---- -- _|_)----|-----()----------- ----------()------------x-----

14, Av. Pr. Franklin Roosevelt, 94320 Thiais, France Phone at CCMIX +33-1-57 42 91 09

Stefan,

Thanks for the input. My system will change the samples in memory fairly regularly, but only to a certain point; during a certain stage of work. After that, the samples are likely to stay the same, so it's hard to say where my model sits in the whole Giga scheme. But I have considered the possibility of using _both_ sfplay~ and buffer~/groove~. If I could devise an abstraction/poly~ which took the same arguments for either of the two options, then I could create a system which dynamically "decided" which to use, based on context/usage (and "re-usage"). But I'll take your advice and build a patcher to test them... If I can manage to build both versions using the same arguments, it should make testing very simple.

Also, if you're wondering why all this is an issue? Yes, I am dealing with _far_ too much sample material to fit into memory. Ouch!

J.

This thread was written quite a while ago, but I am still encountering similar problems. I want to have a huge amount of soundfiles at hand to play them back without "any" latency. streaming them from disk gives me a big latency of course (even though SSD drive) and the big problem is, even though it doesn't even slightly hit the RAM's maximum size (2-3Gb in 32-bit) I can't load more than 2499 files into my sflist~. Anybody had a similar experience? It would be amazing to find a solution I've been spending weeks on that.

as long as we are not talking about several gigabytes of audio i would like to make the following statement: sampling should normally always happen from RAM. playing something from disk isnt exactly what a "sampler" once was, it is only an additional function in order to save RAM and/or the time which it takes to load a lot of stuff into memory.

zero latency from disk is impossible in a real time situation, it can only work in an application where the note events to be played are known before, so that the audio files can be loaded _before they are needed.

you jmight think it is a bit of an overkill to load 10,000 files into 10,000 buffers, but this seems to be your only option when you want to have 10,000 ready to be played live from a physical controller.

i wouldnt consider streaming samples on the fly :/ ive been trying similar things and facing similar problems . the solution i found was based on lets say "dynamic allocation" and "garbage collection" .

0.An empty buffer (in my case polybuffer) 1.A list of samples that contains paths to the appropriate files . created manualy or automated 2.Filling the buffer with dedicated sample file at a appropriate time . 3.cleaning memory from unused soundfiles manually with semi-automated structure or automatically after period of time . or frequently used sound files stays in memory . or even loading last used sounds at a initiation time .

as far ive been measuring , hitting the list to retrieve path ,filling buffer and your playback object at the first time will introduce really small latency that is acceptable (i cant hear it), the second hit doesnt require loading procedure ,so no latency is introduced there . maybe its worth of your consideration

Thanks for your replies! But what I am working on is a system that doesn't know beforehand what might happen. That would mean that the OS should be capable of handling huge lists of soundfiles being prebuffered and postloaded from (a very fast) harddrive, so no hearable latency would be expected. That works pretty well for me, apart from the mysterious problem of the number 2499 which seams to be some kind of a threshhold to Max or the OS. I am still very much interested in this kind of system as I am talking about handling not thousands but millions of soundfiles at a time. (not voices though!) Have you encountered "the problem of 2499" before?