Sorry, yeah, that’s what I’m after. It’s the processing time I’m chasing down. For the 64 sample window, looking at around 0.2ms, the 256 jumps up to 0.8-1.0ms, and 768 is like 3-4ms (of processing time).
I have noticed some funny business where sometimes I switch to @blocking 1 and things speed up, but I haven’t been able to isolate/narrow down when/why that’s happening.
It’s just a tricky as there are so many objects and related buffers that changing all the @source / @features for each fluid.buf..~ objects takes some time, as does changing the buffer~ sizes based on the amount of analysis frames that get returned.
Don’t know if this is a viable option at all, but it would be amazing if an object set to @blocking 2, if it is presented with a buffer~ that is the wrong size, or has no size, that it resizes the buffer, once. So basically whatever loop throws up the “buffer is wrong size” error just resizes the buffer instead (internally in @blocking 1 I guess) and then carries on in @blocking 2.
edit: made this a feature request here to not “cross streams”.
OR if there’s a better/faster way to just the list of values that a buffer~ will require than checking the attrui for samps (which never seems to line up with the “actual” size in ms) and then checking an info~ for amount of channels.