Fluid.bufstats~ inconsistent @startframe behavior?

This seems like a bug to me, but it may just be an edge case oversight so posting it here before going to the github with it.

I’ve been updating my JIT edge frame stuff (based on the discussion in this thread) and to do this I’ve been dynamically adjusting the @startframe I’m using for fluid.bufstats~. When doing this I was getting an error in the console:
fluid.bufstats~: Weights buffer invalid size

I was confused because my descriptor and loudness frames are exactly the same (10 frames in this case).

Screenshot 2023-07-02 at 11.03.02 PM

After poking and prodding I realized that @startframe in fluid.bufstats~ is being applied only to @source and not @weights.

As in, even though I am sending in source and weight buffers that are the same size, fluid.bufstats~ is truncating the @source buffer based on the @startframe attribute, and leaving the @weights one untouched, hence the error.

Checking with the reference file and the conditions for @weights are listed as:

a single-channel
exactly the same amount of frames as source
all values must be positive (anything lower than 0 will be rejected)

It doesn’t say anything about how @startframe factors in. In my case my @weights input is the same amount of frame as @source and all other conditions are correct as well, but it still returns an error.


So to me this seems like an unconsidered edge-case and the reference is correct in that the source/weights should be the same. It would then follow that @startframe would (internally) apply to both the source and weights buffers. Otherwise it creates weird edge case plumbing where modifying @startframe (and presumably @numframes) would require a bunch of fluid.bufcompose~-ing of the weights buffer in a way that seems needless and confusing.

It’s a bit more annoying than it seems to to code around as well due to buffer threading and fluid.bufcompose~ since you need to manually resize the @weights buffer otherwise fluid.bufstats~ will still complain about size.

1 Like

it does indeed seems like an oversight. Good news, a real bug. Bad news: please put on github since I’m about to go offline for 4 weeks so it won’t be looked at for that long except if anyone else wants to check it there.

If not, then I’ll look at it when I’m back in August.

thanks for the report


Git issue created.

What’s also annoying is that similar to the weird outlet order bug I found a while back, I need to bake in a workaround otherwise things completely break for people not on the very latest FluCoMa update. I can specify it needs to be 1.0.7+ or whatever, but if that’s not the case this would completely break all descriptor analysis in SP-Tools (once I implement this).

I suppose if you’re in there fixing something, I may as well bump this old request about adding proper dbtoa scaling to fluid.bufscale~.

I forgot this was in a separate object (fluid.bufscale~ vs fluid.bufstats~) but got excited about it so leaving it up!

I’m not certain this is a bug - I need to investigate. As for dbtoa, don’t hold your breath :slight_smile:

1 Like