That’s a good point.
I guess fundamentally because that’s the available interface option… I’d sooner prefer @output pitch log so that all the stats are computed in the log domain (where relevant), but any deviation outside of the presented options involves a lot of peek~ / uzi → [Max maths] → peek~ again to carry on with the process.
edit:
[Actually it would also get quite confusing as, as much as I’m terrible at counting channels/indices, it’d be even worse if what was being fed into fluid.bufstats~ was in some arbitrary order which I’d have to know.]
Don’t get me wrong, I do do this all over my patch. Actually, checking now, it looks like everything except my MFCCs processing chain is doing a peek~ → Max → peek~ round trip to get the values I want, and to get them in sensible ranges:
(in looking at this, I’d have a helluva time figuring out what’s actually happening here if this was someone else’s code, but that’s another (well-trodden) story)
And even the MFCCs one is not without it’s funny business. Since I only want mean/std/min/max I have a nice cascade of fluid.bufcompose~s to put something together:
All of these are post-fluid.bufstats~ though, so it’s just the final pruning and scaling, though it would be ideal to do that pre-fluid.bufstats~ in all the cases. Or for that matter, if I’ve come out of the fluid.verse~ I can just do the stats on the list manually…