Making sense of (buf)stats

[rodrigo.constanzo]

@rodrigo.constanzo

My first use case is figuring out how long a sample sounds , to keep as a statistic for querying a database.

@a.harker suggested getting a time centroid, by sending irstats~ a center message. This, very usefully, gives the moment in time of the sample where half of the energy is on each side of the sample (I think). This is better than what I was initially thinking of using an RT60 measurement, which I was told was problematic.

Then using fluid.bufstats~ , and taking the “mean of the derivative” (more confusing sounding than it is, since it’s just the first value returned by @numderivs 1 ) to see the change over time. @tremblap also suggested taking the standard deviation of the derivative too, though I’m not sure how to make ‘real world’ sense of that one.

So between those three stats, I’ll probably come up with some kind of weighting to get a single number of “long-ness” per sample.

So at this point I have a question about weightings and aggregate statistics. If I want to weigh together three numbers, which are in different units (the “time centroid” is a number in ms (or samples), and I have no idea what units the mean (normalized amplitude I guess for audio?) and standard deviation of the derivative are in), what would be a good way of doing so?

Bumping this thread, as I’m running into this problem again/now.

To resummarize, I have a few different descriptors that I want to query/compare against an envelope follower so that the busier the playing is in my live audio, the shorter the samples that are queried from the database, and similarly, if my playing is more sparse, to have it learn towards longer samples.

So I can do a single->many mapping where the envelope follower is just scaled to each descriptor, but that won’t really give me any weighting, which is useful if one value is spiking but others are not.

How is this generally handled, in statistics? Should I come up with a(n arbitrary) function that combines the three descriptors together into a single value, and then match against that? How would that work in terms of turning that information back into an actionable query for entrymatcher~, particularly if the <-> matcher is euclidian (??).