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:

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.


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:

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: