Forums > MaxMSP

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

July 3, 2013 | 4:51 pm

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!


July 3, 2013 | 5:30 pm

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~

http://cycling74.com/docs/max6/dynamic/c74_docs.html#sflist~


July 3, 2013 | 6:04 pm

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?


July 3, 2013 | 6:36 pm

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


July 4, 2013 | 4:21 am

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?


July 4, 2013 | 4:57 am

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…


July 7, 2013 | 12:32 pm

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…


July 8, 2013 | 1:58 am

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


July 9, 2013 | 11:25 am

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!


July 9, 2013 | 11:27 am
– Pasted Max Patch, click to expand. –

July 9, 2013 | 12:03 pm

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


July 11, 2013 | 12:13 am

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…


July 11, 2013 | 2:51 am

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


July 13, 2013 | 8:01 am

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


July 13, 2013 | 11:13 am

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


July 13, 2013 | 11:50 am

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

http://pastebin.com/DYPRTnQZ

System : osx 10.6.8 – max 6.1.3


July 13, 2013 | 12:36 pm

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!


July 13, 2013 | 8:50 pm

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


Viewing 18 posts - 1 through 18 (of 18 total)