Are there any plans to expand the
fluid.bufstats~ paradigm to work with stats of stats?
As in, for the database/querying thing I’m building I have computed a whole load of stats for each sample, and then have them all jammed together in a single coll/text/json file.
I would like to then have some statistics on all of the loudness-es across the corpus (min/mean/max for normalization for example), and same goes for most other statistics.
For now this is mainly for input->corpus normalization, but I could see this being useful in general to know what’s “in there”.
At the moment I can
uzi through all of the entries and
fluid.bufcompose~ them into a single buffer, then run some stats on that, but that can start to get real fiddly if I have to do this with loads of different statistics (my current corpus has 22 data points per sample).
I don’t know how this would work in the current
fluid.bufstats~ paradigm as it takes a single buffer as input. I guess being able to refer it to a named
polybuffer~ would be good, but that brings complications that have been mentioned elsewhere.
At the moment I’m using @a.harker’s alpha/beta
entrymatcher~ update which computes statistics for columns of data. This works well but doesn’t cover all the desired stats. Plus it means moving from buffer->list->buffer to get back to the
Is there an approach on the roadmap for something like this?
Or better ideas on how to go about it?
i’m sure @weefuzzy will have some wisdom here, and there are definitely (for toolbox2) ways of dealing with this. It is actually the raison d’être of the whole project
It will be slightly fiddly at the moment, yes.
If you have
N entries in your corpus, each of which has 22 data points that you wish to summarise, then you’ll need to compose a buffer
N frames long, with 22 channels. I think what adds to the fiddleyness is that, if you’re starting from outside
buffer~ land, getting data in channel-wise rather than time-wise is harder (or at least feels harder). We can’t use jitter tricks so easily, because
jit.buffer~ uses planes for channels, rather than an extra dimension.
Fundamentally: patcher languages make iteration a bit of a drag, and
buffer~ isn’t really a 2D data structure as far as Max is concerned.
So, in this case I’d jump into
js. The attached marshalls some data out of a
coll and into a
buffer~ for further stats-y goodness.
collbufcorral.zip (161.1 KB)
Cool, I’ll have a play with this and see if I can generalize it a bit more. (I don’t think I need all 22 stats-of-stats (nor am I sure which stats-of-stats I want (is there a name for stats of stats? (are they derivatives? (can you have a derivative of a derivative (without it being a 2nd order derivative?)))))).
Hope it’s useful. I think there’s a mistake, in that it runs
bufstats~ too many times (once per
coll entry ), but that’s simple enough to fix.
is there a name for stats of stats?
maybe pooled statistics, not sure, for my stats know-how is pretty bad
are they derivatives?
Not in the usual mathematical sense. A derivative is an expression of how one thing changes with respect to another
can you have a derivative of a derivative (without it being a 2nd order derivative?)
That’s what a higher order derivative is (glossing over the whole messy business of derivatives in multiple dimensions)