While creating a large dataset from a previously analyzed database, I’m using fluid.list2buf in a loop.
Frequently, and totally unconsistently I’m getting the error
fluid.dataset~: Empty buffer
This is what I guess is happening. It’s a timing issue where the t b l is already banging out
the temp buffer before listfunnel has finished ???
I modified the abstraction to this:
It works, but slows down the patch by a good margin.
Any other idea how to avoid the empty buffer error?
Thanks, Hans
Are you deferring the return to the top of your loop?
Thanks @jamesbradbury. Indeed that was the missing step.
I sometimes don’t think of a certain branch of the patch being a ‘loop’, particularly when
iter is used. Putting a deferlow right after the iter fixed the problem.
I also went back to this article and got a refresher on the whole topic:
Looping is always clumsy in Max. I have a little javascript abstraction I use to make it a bit simpler by essentially making a for loop construct a bit simpler to deal with.
Thanks @jamesbradbury! I 'd been about to come on and say this was probably a thread-thing (and thanks @tutschku for sharing the C74 resource, always valuable!)
The issue in this case is that the fluid.bufresize in buf2list can make it harder to reason about ordering, because it will always wait for the buffer to have finished resizing before proceeding, but doesn’t really protect against timing confusions creeping in elsewhere: changing the size of a buffer (or just setting samps / size) will always defer, making this object / paradigm just plain tricky in a scheduler-thread context.
I have an experimental version of an external version here, which would behave differently, by refusing to resize buffers if called from the scheduler (and emitting an error to that effect), which might be clearer and more usable. I’m still deciding…
My tired and sleepy eyes read this as “emailing an error to that effect”, and I was like damn!, that’s quite a bit lower aggro than the yellow text in the Max console.
