Ok, finally got around to testing this today.
Quite handy!
I tried it on some longer/weirder audio (jongly.aif has some fairly clear segments, so clumping here doesn’t seem musically intuitive (for me)) and the results were interesting. Wish there was an easier way to visualize the difference in slices (in Max-land) as I’m getting nearly 50% reduction, and short of playing all the segments and guessing, it’s hard to actually make sense of what that means, for each algorithm.
A small/silly thought is that the minimum slice length could be significantly bigger. I put a file in that was around 1min and one of the segments (even after reduction) was around 70ms, which at a “gestural” level is microscopic. Perhaps this could be set as a % of the overall file length, or related novelty kernel size.
It also got me thinking that this could be a great way to segment so higher level ‘gestures’ which can then allow each individual subsection to be (automagically, of course) segmented with bespoke values. This gets tricky obviously, but I was picturing some kind of interface where you do everything that’s happening now (perhaps with the faux “live” thresholding like I suggested above) and then each individual top-level section gets a tiny UI slider or threshold where you can manually tune the settings for each (via fluid.bufampslice~) to get the right sensitivity… per-section/gesture.