We have discussed questions about wrapping our head around the buffer channels and indices in the past. Here is a patch where I’m analyzing a larger sound file, slice it with onset slice, then use @danieleghisi 's ears library to crop and fade to finally calculate mean values of loudness and peak. My question is around the analysis and if the (working) method in this patch is the best approach. My solution is probably convoluted and could be replaced with something more efficient. I’m not looking in to coding in javascript. Thus plain Max only!
Thanks, Hans
For some additional context: I will use the loudness and peak values to decide, whether I will keep a slice (turn it into a sound file with ears.write) or discart it, if the loudness/peak is below a threshold.
@tutschku : Hi Hans I cannot really help on the flucoma streamlining, so this is just a sidenote.
I’ve made a bridge of the Essentia descriptors inside ears, which will be in the summer Patreon release (but I can send a pre-pre-release if you need it), so that if you need a mean loudness descriptor you may just go with, say,
[ears crop~] → [ears.fade~] → [ears.features~ loudness @ampunit db @out m] → mean loudness
This will output the mean value; a timeseries would be output by [ears.features~ loudness…] and an interpolated buffer would be output by [ears.features~ loudness~]
That being said, from my experience the quality of flucoma descriptors is much higher than Essentia, so this is by no means a replacement for your patch, just a quick’n’dirty solution. (In the past I have sometimes started with Essentia features and progressively replaced by better ones when I needed them.)
@danieleghisi , thanks this is very good to know and I would have a peak at a release whenever you get to it. My approach is always two-fold. I’m looking for solutions for my own work, where I don’t shy away too much from complications, AND I’m trying solutions which are easy teacheable to composers, who have little to no programming background. This entire buffer poking in flucoma is necessary the way buffers are used to hold the analysis data, but it is NOT easy to get to specific values without quite a lot of channel counting, knowing which descriptor is where, how statistics are calculated (the 7 values), etc etc. I should probably start learning java script at some point…
Hi Hans, I understand. I’ll send you a private link. (If any other flucomers want it just drop me an email.) The patreon dev-release will be ready at some point in the summer (and will also hopefully include, thanks to the work Andrea Agostini and the suggestions of @a.harker and @weefuzzy, the ears.process~ module that has been much dealt with in this forum as well)
Nice! I’ve now remember that I almost, almost had a version of this completely working last summer before I got pulled away to other things. The DSP side was happy enough, but I got stuck with getting schedulers to update reliably in the processors when one needed to fire in messages. I shall now rummage through your repo to see ho w you and Andrea tackled it
Credit goes all to Andrea, honestly, who I think relied in part on Alex Harker’s code for his externals. I did not do much! (As I said, it was a task a bit outside my coding confort zone…) Credit goes to them!
That being said, I find Andrea’s system quite nice, cause there’s a way of clocking things inside the “poly-like” patch, so you can use [metro], or play a bach.roll, etc., and bounce things off-line. It’s still very raw but it starts working… I’m sure there are catches here and there, if you spot them I’ll notify Andrea
The thing that would make it perfect would be if the poly-like patch could be saved within the patch, but that seems a longer shot… (I’ve always hated poly~ for this)
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:
