Alpha-08: 2 new objects, and last interface change
date: 15 June 2019
New Objects:
NoveltySlice: a realtime version of the buffer based algo!
AmpSeg/BufAmpSeg: an amplitude based segmentation powertool
New Features:
BREAKING CHANGE: (buf)onsetslice: “function” is now “metric”
bufnoveltyslice: now segmenting on other features (mfccs, pitch, etc)
BREAKING CHANGE: the threshold of bufnoveltyslice are now more stabble but will change some of the values.
BREAKING CHANGE: (BufOnsetSlice, BufTransientSlice, BufNoveltySlice) the indices buffer does not return the query boundaries anymore, just valid detected onsets.
(buf)pitch now has ‘minFreq’, ‘maxFreq’ and ‘unit’ (MIDI conversion)
New Examples:
(SC) working 2-passes-folder-load-bufcompose
(SC) proper MFCC example (thanks to Sam)
(max: removed dependencies on descriptor~) (SC: new example) now using fluid.bufpectralshape and fluid.bufstats in all NMF
Bug Fixes:
many again!
Known Bugs:
HPSS still cracks when percussive filter is violently move up
I often get 0 as my first slice (i can’t remember a time or produce an example where I don’t), even if none are found. Is it the situation now, and going forward that you can expect to see 0 returned always? Can we reimplement boundaries ourselves by just appending the length of the @source to the slices?
I can’t verify this - but I assume it is just an onset being a triggered at the start.
It adds an extra step if you care about the end of the file (for slicing out whole segments) but makes sense to not return something which is not a slice. At the same time, it feels weird because I don’t know why I get 0.
Dear both. Thanks for your feedback.
A few answers inline:
for the code, yes. for the bugs, there will be 3 - private, public and here, for obvious reasons. If you cannot find something in your favourite repo, just post a bug report and we’ll take care of that.
There are too many, and changes. Check the few bugs you had, they are sorted. All of them, apart from the 2 identified as known bugs.
You should now get that only with sounds starting with no silence. If you get one with a sample starting with silence, then let us know as this is a bug.
This new interface comes from many critiques from @rodrigo.constanzo that the edges of the analysis window are not necessarily onsets and/or offsets. Also, if you look carefully, some objects (bufampslice) have onsets and offsets, which are 2 different states, as discussed previously. You might want to ignore one or the other. You’ll always get one offset for one onset, as you always are bounded by an infinity of digital silence…
This does help thanks. It makes sense to not have anything but a slice point in the data that is returned. There are ways to check if the end and start boundaries are slices and they can be appended/prepended in response to this (at least in a context where it is important to know the slices + boundaries).
If that’s the case, does that the make this issue from a while back relevant again?
If an actual onset will be triggered at time 0 (unless there is pure digital silence), that means that @debounce/@minslicelength could effectively lock out a “real” onset if it happens within the time between 0. and @minslicelength.
no, because it will(should) only trigger when the conditions are met (digital silence is an example I gave - I get different behaviour depending on different values of thresh and different algo/objects, as expected)
I’d recommend you experiment with them, and see if you can find real-life problems. We have gone through a few months of dev time on each, so we are careful trying to catch all issues, but this is why you guys using them is so important: you will use other use cases that might highlight some shortcomings bug and/or unexpected behaviours… and also misunderstanding of various features we implemented, to help us focus on dissemination priorities.
So at the mo: you get indices at the places you should, aka when the onset function is triggered. For some algo, going from digital silence is a huge step, and for others it isn’t.
I’ll whip up a test patch, but I was just going by what @jamesbradbury reported of getting an “onset” triggered at 0, when presumably there wasn’t one, which could have the knock on effect of what I suspected.
Ok, here’s some odd behavior. (not making a separate bug/issue thread yet, as it could be user error)
If I make a @source buffer with three onsets in them, and set fluid.bufonsetslice~ on it, I get the correct amount of samples, but the wrong positions in the sample.
(it took me a bit to figure out why I was getting even weirder results until I realized that (confusingly!) @minslicelength is in hops and not samples like in most other places…)
nice catch! These are surreal results, and we’ll need to chase them indeed. I’m sure you appreciate their poetry though: 3 results, of which 2 values are similar, implies some sort of parallel dimension…
