sflist~ can't handle more than 2200 cues? "error opening file, err -1"? HELP PLS

Jul 3, 2013 at 4:51pm

sflist~ can't handle more than 2200 cues? "error opening file, err -1"? HELP PLS

Hello everybody,

I have a strange problem using sflist~:
For lists larger than about 2200 cues I get the following error message(s):

sflist~: can’t open wave file soundfile
error opening soundfile, err -1

This happens for every file exceeding that number.
Max itself seems overcharged. It doesn’t show the proper symbols in the bottom bar anymore, instead: pencil.svg patcherwindows.svg presentation.svg etc. Also keyboard-shortcuts don’t work properly anymore.

When I empty the lists everything works fine again.

So here’s my question: Why the heck is that?! Is there a maximum number of files that MAX is able to have prebuffered at the same time?

It is not a RAM issue neither. 3000 files use up about 30 MB, which cannot be problem at all, not even in 32-bit.

And there is no difference whether I use let’s say 5 sflists~ (named differently of course) and load them with 1000 files each or one single sflist loaded with 5000 files neither. I always get the error messages.

If anybody has any clue about that mystery I’d be so relieved. This thing’s keeping me up for long now… Thanks a lot in advance!

Jul 3, 2013 at 5:30pm

Please provide OS and I/O Vector Size and Signal Vector size from Audio Settings.
Since 64 bit is an option you’re on Max 6.1+ I suppose.
Note that “Preloaded buffers are 4 times the size of the buffer size per channel of the audio file.” How are you calculating the buffer size needed by the files you are loading? Are other buffer~ or preloaded sfplay~ objects in use?
Here’s the Max 6 refpage for sflist~


Jul 3, 2013 at 6:04pm

I am working on OS 10.8.3, Max Version 6.1.3, 32-bit.
Vector Sizes are: I/O 256, Signal 256.

Even though it’s 4 times the prebuffer’s size it’s almost nothing with a buffer size of 16384 (default) at single channel use. The system’s activity monitor confirms that. I also checked other buffer sizes, which didn’t change anything.

There are no other buffers or sflists burried in the patch. And as I wrote, I also checked if it makes any difference to divide the lists into several sflists or into one. Same problem.

When the “over chargement” takes place the Audio Status for example doesn’t either open at all “can’t load patcher: error -1 opening Audio Status.maxpat” or appear in an inspector-like table view without its usual UI.

Any ideas?

Jul 3, 2013 at 6:36pm

No ideas. Maybe a bug having to do with 32 bit calculation. Can the sflist deal with 2140 items? How about 2150? See


Jul 4, 2013 at 4:21am

I tried to manually load different chunks of files.
When I load smaller chunks of files I can go further beyond the proclaimed 2200.
There is no specific error with the number 2140, but is it possible that Max can’t handle the speed at wich the files are being loaded?
the object “speedlim” (which also appears in the sflist~ help file) does not make much sense as it doesn’t slow down the loading process but just reads in intervalls, therefore misses files.
Any idea to that approach?

Jul 4, 2013 at 4:57am

I guess I was to quick on that point.
I used a delay now that works fine, loading samples in time intervalls (I tried 10ms and 50ms), now the magic number is 2499. There it stops working and for the rest of the files I get error messages…

Jul 7, 2013 at 12:32pm

It’s really annoying:
when I load the files manually by using dropfile, loading chunks of let’s say 600 files at once, I can load up to the maximum of sflist (~32000) cues with no problems.
But no matter how I use prepared lists it stops at 2499.

What kind of strange bug is that?

I think its time for some serious MAX-staff’s help on that…

Jul 8, 2013 at 1:58am

did you send a bug report to Cycling ? ( http://cycling74.com/max6-bug-form/ )
i don’t think you’ll have better luck with any alternative, as sflist should theoretically be your tool of choice there. And i’ve also been experiencing strange behaviour when filling automatically an object with a list, though for me it was with umenu which wasn’t filled fast enough to respond to messages after the filling with the [trigger] method. In my case it might be because umenu is graphical ui hence low priority of the scheduler, but sflist~ is no graphical ui object so it shouldn’t happen for this reason by any way….

Jul 9, 2013 at 11:25am

Could anybody maybe try if he/she can load more than 2499 files into sflist~?
Just use the following patch and drag-drop lots of aiff/wav files (at once) in the dropfile.

This would be a huge help. Please report whether you’re getting any error messages!

Thanks a lot!

Jul 9, 2013 at 11:27am
– Pasted Max Patch, click to expand. –
Jul 9, 2013 at 12:03pm

heh… i’ll have to admit, i’m not sure i have more than 2499 files to feed sflist~….

Jul 11, 2013 at 12:13am

Well just for the sake of a little test, if you don’t mind, you might multiply-copy (1->2->4->8 etc.) There you go pretty fast, won’t take very long.

Could somebody do me that favor? I still don’t have any idea if it might just be my machine that’s causing the trouble…

Jul 11, 2013 at 2:51am

can’t right now, i’ll try tonight with a small soundfile

Jul 13, 2013 at 8:01am

Thank you very much Vichug! How did it work out?

Jul 13, 2013 at 11:13am

hah… “tonight” was not the night…. i’m trying right now. If you don’t have news soon, it’s because i crashed :p

Jul 13, 2013 at 11:50am

So… i didn’t crash, and i couldn’t go past the 2472th element. Pastbin of max windows reporting here :


System : osx 10.6.8 – max 6.1.3

Jul 13, 2013 at 12:36pm

Thank you very very much Vichug!
The result shows that it’s not my machine, but a bug in a Max obviously…

Time for a BUG FIX guys!

If any solution shows up, I’ll post it here.

Thanks again and enjoy the rest of your day!

Jul 13, 2013 at 8:50pm

anyway, you need to send a proper bug report to cycling if you expect any reaction from them.


You must be logged in to reply to this topic.