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

    Jul 03 2013 | 11: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!

    • Jul 04 2013 | 12:30 am
      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~
    • Jul 04 2013 | 1:04 am
      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 04 2013 | 1:36 am
      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
    • Jul 04 2013 | 11: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?
    • Jul 04 2013 | 11: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...
    • Jul 07 2013 | 7: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...
    • Jul 08 2013 | 8:58 am
      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....
    • Jul 09 2013 | 6:25 pm
      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 09 2013 | 6:27 pm
    • Jul 09 2013 | 7:03 pm
      heh... i'll have to admit, i'm not sure i have more than 2499 files to feed sflist~....
    • Jul 11 2013 | 7: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...
    • Jul 11 2013 | 9:51 am
      can't right now, i'll try tonight with a small soundfile
    • Jul 13 2013 | 3:01 pm
      Thank you very much Vichug! How did it work out?
    • Jul 13 2013 | 6:13 pm
      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 | 6:50 pm
      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
    • Jul 13 2013 | 7: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!
    • Jul 14 2013 | 3:50 am
      anyway, you need to send a proper bug report to cycling if you expect any reaction from them.