# Fluid.bufstats~ inconsistent @startframe behavior?
**URL:** https://discourse.flucoma.org/t/fluid-bufstats-inconsistent-startframe-behavior/1952
**Category:** Bug Reports and Issues
**Created:** [July 2, 2023, 10:05pm UTC](https://discourse.flucoma.org/t/fluid-bufstats-inconsistent-startframe-behavior/1952 "2023-07-02T22:05:28Z")
**Posts on this page:** 6
**Page:** 1
### Author:  [@rodrigo.constanzo](https://discourse.flucoma.org/u/rodrigo.constanzo)
#### Post date: [July 2, 2023, 10:05pm UTC](https://discourse.flucoma.org/t/fluid-bufstats-inconsistent-startframe-behavior/1952/1 "2023-07-02T22:05:28Z")
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](https://discourse.flucoma.org/t/adding-lookback-to-ampslice-based-jit-onset-detection/1938/8)) 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).
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:
```auto
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.
---
### Author:  [@rodrigo.constanzo](https://discourse.flucoma.org/u/rodrigo.constanzo)
#### Post date: [July 2, 2023, 10:44pm UTC](https://discourse.flucoma.org/t/fluid-bufstats-inconsistent-startframe-behavior/1952/2 "2023-07-02T22:44:21Z")
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.
---
### Author:  [@tremblap](https://discourse.flucoma.org/u/tremblap)
#### Post date: [July 3, 2023, 12:09am UTC](https://discourse.flucoma.org/t/fluid-bufstats-inconsistent-startframe-behavior/1952/3 "2023-07-03T00:09:22Z")
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
---
### Author:  [@rodrigo.constanzo](https://discourse.flucoma.org/u/rodrigo.constanzo)
#### Post date: [July 3, 2023, 8:15am UTC](https://discourse.flucoma.org/t/fluid-bufstats-inconsistent-startframe-behavior/1952/4 "2023-07-03T08:15:19Z")
Nice!
[Git issue created](https://github.com/flucoma/flucoma-max/issues/366).
What’s also annoying is that similar to the [weird outlet order bug](https://discourse.flucoma.org/t/non-standard-output-order-of-fluid-bufsinefeature/1802) 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).
---
### Author:  [@rodrigo.constanzo](https://discourse.flucoma.org/u/rodrigo.constanzo)
#### Post date: [July 3, 2023, 9:09am UTC](https://discourse.flucoma.org/t/fluid-bufstats-inconsistent-startframe-behavior/1952/5 "2023-07-03T09:09:59Z")
I suppose if you’re in there fixing something, I may as well bump [this old request](https://discourse.flucoma.org/t/fluid-bufscale-scale-options/1440) about adding proper `dbtoa` scaling to `fluid.bufscale~`.
edit:
I forgot this was in a separate object (`fluid.bufscale~` vs `fluid.bufstats~`) but got excited about it so leaving it up!
---
### Author:  [@tremblap](https://discourse.flucoma.org/u/tremblap)
#### Post date: [July 4, 2023, 3:41am UTC](https://discourse.flucoma.org/t/fluid-bufstats-inconsistent-startframe-behavior/1952/6 "2023-07-04T03:41:59Z")
I’m not certain this is a bug - I need to investigate. As for dbtoa, don’t hold your breath 🙂