Fluid.bufstats~ - Not enough frames

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.

fluid.bufstats~ @source ---onsets_loudness @stats ---onsets_loudness_stats @numderivs 1 @startchan 0 @numchans 1

Wouldn’t this return the stats on whatever amount of frames are in the @source buffer?

Here is the patch/device if relevant:
http://rodrigoconstanzo.com/party/cloudv2.1.zip

you are using blocking2 right? To be quick, this mode is not resizing so it is on the user to do their maths properly :wink:

my trick is to run everything in blocking 1, check the sizes and fix them right (so I don’t have to do the maths)

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…

I’m doing all of that.

The strange part is that it only happens once in a while. So it’s not the buffer, the buffer size, or something obvious like that.

I was getting some rare (yellow) errors with irtrimnorm~ which I tracked down, but I still don’t see what that could have to do with this.

no you’re not :wink: Your buffers are instantiated with no duration. That is bad. It used to not work at all, now it almost works for most objects.

I would instantiate like this:
[buffer~ —onsets_loudness_stats @samps 1]
and then everyone is happy.

What is the deal with this? I never give a size and stuff works. Is it just good practice to give it a size anyway?

You’ve just not used Max for long enough :wink: 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.

I’ll go ahead and do that.

Either way the error message reporting could be more informative about what it means (destination frames or source frames).

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.

2 Likes

Hello !

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.

See here:


----------begin_max5_patcher----------
1339.3ocuY0kjiZCD9Y6SgJdLkiKj3+7jSN.4Br0VSIiEdXCH4BI1LS1Zmyd
ZIAr3YvFaLLtpAKjkT2eec2pao4GqW4rW7BS5f9CzWPqV8i0qVY5R2wpl2W4
TReIsfJMCyIUTVx3JmM1eSwdQY5mlppoEHQFRRKOUjyOhpnJV6330k47Blxr
H3lNOQUoOCi7oJVpxpDAgQac2f7sekjnehg1nu9qERTqZWI2ldyOXTBw9u86
dDGce+b8Z8iMyCr.otmU0gNlDkyQpmYn80YYrp1ocphIgUgpxE7m.NfkJp4l
EhLQdfP1F.LPH99IBRzTHBKRuayFNvptXs5F3Zz1jKpssrgsK0qmX1kwwYCx
YOkezoah8ATRGOSqnkLEq5IFmtuvLa2YzpCVVQESkmhTBEX9U4kLsEuTNQ+Y
OehgRbCmfcLz4S.ZM90i6I6MQFH1y.cR7DXff4jA96+RGGm9LkyYES1f5ZhH
ibm.Z7mBZxJDvJOw3RO+YOtLSTURMRIb.Hhm6H0GB99glvtOM3i8ma3+P6J6
Euj6JO6aJyY+KrteHrsTpD5MojucuzfuGtMH.9JbxzfL+HmVnICvaTa7GfM7
97iss6D84EaS9jL3+FBucPNgbYNIJzRIA1rsdivI3KwIW1.iiclSHBVMW78h
Rr0GlDYc.hV.TFMinzVi7a5ZkkPEE2cJ2HaJWLwVDr0eeJd5V7dsMyvXxbBb
D49wpYOJigMHdp.0fuqgy4zIFH0CVANEn54YyPOUe3KBwI4AWxjR5Q1GvXVd
QARlySQD2qFslI3JNrqnYV+YUtNewkiis6fmXOpW7TofgsvgN8TIY9+YFMr5
yebsTTWkx.bIekqddhQ2gKevc.1Yw.eYVZ5DQdxxibR7hgbHYK74dgdimO1K
XqG7ASRrehBA9ve4HB+YjGxJpyOrEXCdY1ancMzQyW6fSedRvgyeJASKZWSv
w6hUP6xxTR.C.6nGGwGsaegH8ezWel6z1PEaOSZSQuWgF8FK6QGcNrO0LRk4
7LwCFJYJHBpvOr2mHeh1GaLhHYT+ohbo5LF4VZn+KmOb8UgKgenl3dC469Ne
wdNaLppFdqOSOjKHTkVkReAIH299inc5igR4GjFg.ujJXYY52ln8BabUCRbW
VW0y122L.G8UZ8t681nl59O2DX4pF4YOhGnqch4.SBTm4dx5MF3Pw.e80AMx
2pbfSZXVjqJHxbHInTAT3XBBel1HpNvpt7A9tGIOFD02lxxH4wvr2vBFu3BF
N90fRl7PRN9VXa+YveJ9FhPZUlGVPiFgLCxI5FjS7LEHFOFdHyjfFMtKdIb+
I2hjmicOitUHheTIcCB5iN61zPzSm9NqR1LXiHfb9eSXH53MlWy41WMoScpX
eOuc71APqfrqJH0JjZ2jx6kP68O6TJ.SFuNuwpAfCDoT8Zw6S80chUndiPcQ
HFv.XIiVWnNG+zzTnp1TQgUq9Bxca7F8CuDBNT2JxMI10GH1d4y0UqXlyS4b
MhYsy0cSuG8mw9i8jAt4Wad3tMnkL2zXqpzkZqglAGM.nDz971bE8ssmAXSE
KWCxmAVehW.IQqCdQj.eSKRje.tQ8mM05r6hXXEa+Q8ESzodq59EfvaJRx4X
E8P9u9+f0fFbmsyTn7lAa0ybzLMR6zhhiAdXyfs93zZmEIwEmX7Q7Z7Qzsft
vuaVPYcVJiXNMSSumpDmDUsgVvTS5FesRzAz1ZCZMC2k220LemGcbaVQaIq2
r2kQW7A2JWhoEvR.JmpmkcSFyIHzJk7D0tyk4fFq+45+G3g9+LA
-----------end_max5_patcher-----------
1 Like

Some objects use bins though so it’s not always clear.

Maybe adding some explanation in helpfiles would simply help.

1 Like

I’ve gotten used to most of them by now (I only notice the diff with novelty really), but it was really confusing at the start.

It is the case with “fluid.bufmfcc~” too but a different sampling rate for buffer~ is not a problem at all.

Actually the sampling rate allows you to know the real sampling rate of the values you get in there… isn’t that nice? :smiley: