sfplay from hell
Dear everybody,
I have a problem with sfplay and I hope you can help!
What I need is to play a random choice of 9 samples (named 01.aif...09.aif) on the beats provided by a metro object. All the samples are collected in a folder that I would like to choose on the fly among possibly a lot of them.
I cannot "open" the samples one by one as it slows down the performance quite a lot at fast rates (already at 4 Hz note speed). So I'm "preloading" the entire 9 samples set without "opening" any sample. My intention is to "preload" all the 9 samples in the chosen folder as a complete path whenever I choose one with a populated umenu.
That means that the message to sfplay looks like "preload 2 HD:/Users/me/Desktop/chosen_folder/01.aif"
First problem: the "clear" message doesn't work, the previously preloaded samples are still there.
Second problem: I cannot overwrite a preloaded set of samples using a complete path. Nevertheless I can do it using a reset file in the search path with a message such as "preload 2 reset.aif".
Afterwards I can reload any other set of samples using a complete path... at least on a simple sfpay with few messages, because when I use the complete patch with the full 9 samples instruction Max crashes!!
I checked the messages (the patch is not doing anything else in that moment) sent to sflay and they are correct!
So why is this?
And why in the first place the "clear" message is not working or why I need to use that complicate procedure to preload a different sample?!
Thankyou very much for any help!
all these questions will be answered when you use [buffer~] and [play~] instead of [sfplay~]
ok, do you really think that for managing (as I do in the whole patch) at the same time 14 sets of 9 samples each with different lenghts, that is 126 samples changing on the fly (but only 15 of them playing together at the same time) the couple buffer&play is the best?
I always thought that buffer&play were best in other more rigid purposes, but I might be wrong of course...
Remains the facts that sfplay has a weird and (apparently) undocumented behavior!
Thank you
I can confirm that the 'clear' message to sfplay~ does not work as advertised. That's either a bug or an error in the documentation. However, the 'clear' message to sflist~does work. I suggest that you use that. I'm sorry, I don't understand your description of your other problem with file paths.
I'd prefer not to use sflist as I prefer a more versatile environment and I should create a lot of lists for each "instruments"... something like hundreds sflist objects... too much indeed!
The file paths issue is as follows:
sfplay behaves differently depending on the fact you preload a file such as "01.aif" (that is on the search path) or such as "HD:/Users/myname/Desktop/chosenFolder/01.aif"!
I find buffer~ and play~ (or groove~) to be a better solution for handling many sound files. You have one buffer~ for each file, and as many play~ objects as you require for simultaneous voices. You can simplify loading by typing the name of your file onto the buffer~. If the file is in the Max search path, it will load automatically at start-up. Once you create the buffer~s, stuff them away somewhere in a subpatch, you never have to look at them again. Then you change sounds by telling play~ to use whichever buffer~ you like, by using the "set xxx" message.
Thank you Kurt. Unfortunately this use of buffer is not suitable to my patch. I'll upload it tomorrow so I can show you what is it all about.
I have different sets of sound (from 5 to 9 samples each).I' don't know how long are the samples in advance. I 'd like to choose while performing the sound sets I need... maybe 14 sets at once, that is up to 9*14 samples with durations from half a second to one minute.
I cannot write the name of more that 100 samples while performing or having more the 100 active buffers...
It would be just great if I could preload 9 samples in 14 sfplay, clear the content of one or more sfplay on the fly and preload differen sets in the cleared sfplay!!!
Not to belabor the point, but that is like exactly what sflist~ is for. You preload the cues into the sflist~ (or a whole bunch of different sets of cues in a whole bunch of named sflist~ objects, if you want) and then any sfplay~ object can easily access any list of cues from anywhere in your program. See the 'set' message for sfplay~.
I would use multiple buffers and a few groove objects, like this
Brendan
Of course Roman and Kurt and Brendan are quite correct that RAM-based playback (e.g., buffer~ and groove~) gives the most control, and unless you're dealing with tons of very large samples it's usually entirely feasible. Even if you're dealing with 10 minutes worth of sound samples, and load those in as uncompressed 44.1 KHz stereo 32-bit floats, that's still only about 200MB of RAM, I think. And your computer has how many GB?
Christopher, thank you for your help.
I'm afraid to say that sflist~ has some problems too. For example the "clear"message... well it doesn't work unless you set the sound off even if no sample is playing!!!! Luckily, if I use a complete path in the "preload" message I can apparently overwrite the same cue! a thing that I cannot do with sfplay~ unless I use a "simple name" (that is a file name findable in the search path) object to preload.
By the way I have 2GB of RAM, and 50 MB are already definitely enough for all the sound files I want to use at the same time! This is frustrating because the problem is not coming from the CPU usage, nor the RAM usage... but apparently it is coming from Max!
I prefer not to use buffer~ as previously suggested as this doesn't allow the flexibility I need and I don't need any sound processing (apart form volume of course).
I cannot use sflist~in the "traditional" suggested way as I should create one sflist~ for each list I need to use... definitely too many of them and the performance would be too rigid for my intentions!!
But... everything would be great if sfplay~ and sflist~ would just do the things they are meant (at least in the documentation) to do!!! It's incredible that these two objects, that are IMHO important for a programming based on flexible and intensive sample reproduction seem to be so capricious in their behavior!!
I'll upload an example tomorrow, now it is too late! :-)
Brendan, thank you for your answer!
Unfortunately this is not my case... or well it is my simplest one... now imagine you have 9 buffer~ like yours.
I need to change at once (that is without writing anywhere a single word) the content of the 9 buffer~ objects during the performance simply by choosing a folder where are the new 9 samples. Let's call this folder a soundset. The new samples may have a duration between 1 sec to 1 minute depending on the soundset.
I choose the soundset from a populated umenu obtained simply dragging a folder containing soundsets from the finder to the proper object in the patch. In this way I don't have to collect all the suitable folders with samples in the harddisk every time I switch on the patch. Moreover I can change the soundsets even after having created them during the performance itself: that is a very flexible environment!
Well, what I described is one instrument. And I have 14 of them!
Tomorrow I'll post an example of the relevant part of a single instrument.
Thank you again.
"I choose the soundset from a populated umenu obtained simply dragging a folder containing soundsets from the finder to the proper object in the patch. In this way I don't have to collect all the suitable folders with samples in the harddisk every time I switch on the patch. Moreover I can change the soundsets even after having created them during the performance itself: that is a very flexible environment!"
yea yea, this is what most people do, except they use buffer~ and groove~(if you had soundfiles of 5 minutes duration or more, then it would make more sense to insist on sfplay~(playing files from the hard-drive instead of RAM is better in that case), but you're talking about files with duration of 1 minute or less, so there's no reason why you wouldn't do it using buffer~... if you know what you're doing in Max).
Noob4Life: so you are suggesting me that having 126 buffer~ objects (9 samples for 14 instruments) is a more efficient programming than having 14 sflist~/sfplay~?
Of course my intention here is to have the least CPU usage as the whole patch is already pretty complicate.
@Massimiliano
I think you have some misconceptions about how sfplay~ works. First, the command open does exactly the same as a preload, its just a preload for cue # 1. What it does, is loading the beginning of the sound file into RAM. That takes time. If you trigger and change things at a possible rate of 4 Hz, (which isn't that fast by the way,) and the loading is getting you into trouble, simply check your performance settings. You have to set at least scheduler in overdrive on...
The buffer~ solution for your scenario would still be the best. You can automate the buffer~ loading as you can the sfplay~ preloading. Not much of a difference.
The complete paths have to be one symbol by the way, if there are spaces in the paths, you have to use quotes...
And there is a new object in the edge section called polybuffer~, worth to give it a try...
Btw. 9*14 buffers~ is not so much, as you think 9 and 14 separately. Encapsulation will prevent you from brain explosions...
I load buffer~s worth of hours into my RAM - average 90000 seconds each...;-)
Good luck,
Stefan
Stefan: thank you for your answer! yes I know how sfplay~ works and my problem as I said is not in loading files but in overwriting loaded files... that means loading a new file in a cue where another file was already loaded. This shows weird (though different) behaviors with sfplay~ and sflist~ as the clear message is not working properly and the two object responds differently to complete and non complete path messages.
Of course I work with intensive encapsulation... I was only worried of the CPU usage in having 126 buffers running.
I'll check the two versions: one with sfplay~/sflist~ and one with buffer~ so I'll check the difference in CPU usage.
Thank you
M
buffer~ doesn't take any CPU, it takes RAM... as a preloaded file does. If your sounds are short, it might even take less RAM with buffer~s...
Why do you clear cues at all? You could either overwrite them or simply add cues...
>the two object responds differently to complete and non complete path messages.
How? What is a non complete path? I would only feed complete paths anyway...;-)
Stefan
"so you are suggesting me that having 126 buffer~ objects (9 samples for 14 instruments) is a more efficient programming than having 14 sflist~/sfplay~?
Of course my intention here is to have the least CPU usage as the whole patch is already pretty complicate."
Not at all, that's quite a misunderstanding of what was written(you should take the time to listen to what people(not just myself) are trying to tell you here and try it out before jumping to conclusions), you have maybe 14 buffer~ objects at the MOST(one per instrument) and then switch the files for each dynamically(this modular design is much better, anyways). surely, if you have the umenu setup as you claim, you're able to apply this to buffer~? (this is a very common technique)
2 days ago or so you wrote, "Tomorrow I'll post an example of the relevant part of a single instrument." maybe you should just go ahead and do this already. you're having trouble understanding/accepting all the good advice given to you on this thread. it would be easier to show you what we all mean if we could start from your patch.
you should at least try it since it seems you're unaware of what buffer~ and all the playback objects tied to it are actually for(you state things about 'CPU' and 'sound processing' and 'rigid purpose' which don't necessarily apply to buffer~).
"so you are suggesting me that having 126 buffer~ objects (9 samples for 14 instruments) is a more efficient programming than having 14 sflist~/sfplay~?
Of course my intention here is to have the least CPU usage as the whole patch is already pretty complicate."
Not at all, that's quite a misunderstanding of what was written(you should take the time to listen to what people(not just myself) are trying to tell you here and try it out before jumping to conclusions), you have maybe 14 buffer~ objects at the MOST(one per instrument) and then switch the files for each dynamically(this modular design is much better, anyways).
I'll have to disagree. From what Massimiliano says in the original post, it seems like it will be a like a much better design to load all 126 samples into their own [buffer~] objects. Each of the 14 instruments seems to need to be ready to play any of the 9 samples in their sample set, so I don't see any gain of only using 14 [buffer~]s and reloading them every note. Unless the samples are very long, 126 [buffer~] shouldn't be a RAM issue. As others have pointed out, a [buffer~] doens't in itself use CPU, just RAM, so if you go with this approach 126 vs 14 [buffer~] will not make a difference in CPU (and you should have enough RAM for it as well)--the CPU difference will come with how many [buffer~]s you are playing from at once which seems to be fixed at 14.
Massimiliano: are these samples being played back linearly at normal speed? If so, I would recommend using [count~] to drive [index~] to playback the samples vs [sfplay~] or any of the other [buffer~] objects as this is the most basic way to play through a [buffer~] linearly (although as others have pointed out, you should definitely look at the whole family of [buffer~] objects--[index~], [play~], [lookup~], [wave~], [groove~], [peek~], [poke~]--because they all have their own unique uses). To answer your question about if a [buffer~] playback scheme will use less CPU than [sfplay~] (since most of the responders are just pointing out that a [buffer~] uses RAM and are not addressing CPU use of [buffer~] playback objects), from tests I have done driving [index~] with [count~], it uses somewhere between 1/3-1/2 the CPU of [sfplay~]. Either way, no matter what object you use to play from your [buffer~] it would probably be prefered over [sfplay~] because thinking about other software, this type of instrument based sample playback is usually handled playing samples from RAM versus hard disk playback.
As others have said, bugs or not, [sflist~] seems to be what you'd want if you really wanted to stick with [sfplay~]. From what I gather, you have found two possible bugs/undocumented features? I'd recommend maybe making a new thread describing those bugs (with a more descriptive title) since this thread seems to be focusing on a [buffer~] playback vs [sfplay~] debate for your particular implementation.
Roth wrote: "Unless the samples are very long..."
he said in another post here that they were less than a minute. I've done the same exact thing(for loops/clips) and had no problems switching files within a single buffer~ really fast(i know buffer~ loading is asynchronous but it worked fine for me as long as my samples were under a minute(and of course, sample-rate/bit-depth of files and DSPStatus... would make a difference, too)).
but you're right! creating 126 buffer~s would also work well(not a CPU hit, only a RAM hit).
________________________________
*Never fear, Noob4Life was never here!*
I've done the same exact thing(for loops/clips) and had no problems switching files within a single buffer~ really fast(i know buffer~ loading is asynchronous but it worked fine for me as long as my samples were under a minute(and of course, sample-rate/bit-depth of files and DSPStatus... would make a difference, too)).
Yeah, I figured that would work, but clearly I'm not as brave as you: I hardly ever swap samples in buffers durring performance (unless I have some downtime playing with an ensemble). Probably not necessary, but as I am usually slamming the CPU with DSP stuff, I try to avoid anything else that (I think) might be risky.