What am I messing up here? I thought the new codebase would wait to be done before getting to “write file” portion of the code. I am loading a lot of really big files, so maybe that is the problem?
@weefuzzy will be able to confirm but I think that the wait and the server.sync are doing the same thing so either one would be good but both are not needed.
I am trying to find an error in your code but apart from that it should work. The size of the files shouldn’t be an issue, except if the loading is not stalling the routine… maybe the iterator of the buffer, what is the class of buffers so I can try it?
did you try processBlocking instead of process? For bufcompose it should not make any difference (because we always make it blocking) but it is a good reflex to think of what spawn new thread or not.
also, if that is a large task, I presume your server becomes ‘yellow’ in the bottom right ? It should if you are doing significantly large task on the server thread itself.
if you let me know the class of your collection buffers and the length of the files, I’ll try to reproduce. I have my large 28chan piece which should be a good use case (that is, if SC supports that channel count without crashing, unlike Max
@spluta, I’ll have a look. Just to confirm, it doesn’t appear to be waiting properly before hitting "writefile".postln ? It certainly should, and I’m not sure you should need any of those syncs under the new regime.
FWIW, because FluidBufCompose doesn’t have a threaded version (process === processBlocking as @tremblap points out), then a single sync before “write file” could replace all the waits, because the jobs all line up in the scsynth command queue in the normal way.
In Max, there is sfplay~ which was supposed to support many channel count, but they hardcoded the file size in there so it crashes on anything larger than 2 gig since Max5. i sent a bug report for 6 and for 7. I have not tried in 8… I’ll try that now just for fun
edit and it still crashes in Max8! a segmentation fault… I’ll try the same file with the mc…
edit2 now that is funny: mc.sfplay~ also crashes!
I know this file plays in the Beast SC extension since it was premiered on there with that player, but I’ll try with the native one now.
edit3 DiskIn with proper buffer size works seamlessly. I remember Scott having improved it a decade ago, and now it rocks Now I better go finish that piece and write those unit testers instead of moaning against other people’s bugs