I’m cleaning up the final code for my Cloud HPSS thing, and I’m getting some error messages that I’m not really sure how to interpret.
One is:
fluid.bufstats~: Not enough frames
Does that mean the buffer it is drawing from doesn’t have enough frames? (I don’t even know what that means) or the buffer it is writing to doesn’t have enough frames (also doesn’t make sense).
I’m not requesting an analysis on a certain amount of frames or anything.
I’ve opened your pat and it seems that you are not using blocking 2, so sorry for the misleading hint (still valid hypothesis so I won’t edit)
My next step would be to check if the buffers exist. I think they don’t or at least are not valid length because if I doubleclick on the native peak~ I get an empty buffer… like nothing at all. just give them 1 as size and that’ll help. In Max 7 and less buffers with no length were always creating issues in native max objects…
You’ve just not used Max for long enough Seriously, it used to not work at all. Now depending on Max versions it works a little, sometimes. So old people (like me) use a default value. For instance, in all my perf patches, there is a 1ms size set, then I replace! The other day, @a.harker was surprised you could now instantiate without a duration… so yes :
yes. you loose nothing and gain in stability. And in backward compatibility. Win win win win!
I give my HIRT buffers a size of 1, all the FluCoMa ones I don’t say anything since they all get pushed around in size and channels (except when I’m @blocking, in which case I declare everything).
Still though, in this case there is still in the buffer, the object is just complaining that there isn’t enough things in the buffer, which I don’t undersatnd.
Problem of buffer instantiation are complicated, and API version dependant… I did not investigate too much but the size 0 ones refused to be resized… even with native ‘replace’ message! Hence instantiating with very small value, and voilà! sorted.
Agreed. In this particular case, it’s not helped that the error message is arising from a secondary condition in the code (which is that the number of frames needs to be >= the requested number of derivatives), rather than checking for a 0-length source to begin with.
I often get “fluid.bufstats~: Start frame + num frames (X) out of range.”
I wanted to make sure “startframe” and “numframes” are in samples as specified in the reference ? I have the “feeling” it is in ms.
Sorry if I am wrong.
In fact, I realize that the sampling rate of the resulting buffer after a fluid.bufmfcc~ is NOT the one from audio buffers. This is something I completely understand but I did not know (or forgot).
You should therefore not use “mstosamps~” to get its length.