I’m still building a picture of how we can make a lot of this boiler plate disappear in the longer term. Some of it just needs some better helpers (e.g. the compiled versions of buf2list / list2buf that are in process), or interface enhancements (cherry picking from bufstats, e.g.). Other stuff is more seismic, like being able to just work with lists directly sometimes (which perhaps makes sense for a lot of use cases with slicers, e.g.).
In this particular flow, I think I’d be inclined to use two fluid.bufstats~ and go straight into lists from these to make the selection clearer using $1 (because you don’t need to stay in buffer-land at this point). Of course, if buf2list supported frame / channel offsets, you could skip this apparent redundancy.
Preusmably you want to apply the fades first so that the loudness stats reflect the post-fade truth. Otherwise, I’d be inclined to just do all the analysis once straight after slicing, and throw it in a coll.
As it happens, I tried out an abstraction at our workshop last week, called fluid.buf.pool, designed to streamline the business of building up a buffer with a bunch of stats on a bunch of features. Whilst it gets rid of boilerplate, I think the leap in abstraction was a lurch for the participants:
Patchers:
fluid.buf.pool: https://raw.githubusercontent.com/flucoma/EdinburghWorkshop2021/main/patchers/fluid.buf.pool.maxpatfluid.buf.stack: https://raw.githubusercontent.com/flucoma/EdinburghWorkshop2021/main/patchers/fluid.buf.stack.maxpat (shorthand for bufcomposing feature buffers on top of each other)fluid.buf.dims: https://raw.githubusercontent.com/flucoma/EdinburghWorkshop2021/main/patchers/fluid.buf.dims.maxpat
Help files: