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

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~
https://cycling74.com/docs/max6/dynamic/c74_docs.html#sflist~

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?

No ideas. Maybe a bug having to do with 32 bit calculation. Can the sflist deal with 2140 items? How about 2150? See
http://en.wikipedia.org/wiki/2147483647

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?

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...

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...

did you send a bug report to Cycling ? ( https://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....

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!