Alpha08 - the last Alpha before the Beta!

Here we go! Now we should be feature complete… 2 new objects, and mostly correct behaviour everywhere… until you flag problems, that is :wink:


I hope you enjoy!

Change Log:

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
  • NMF still creates NaNs in some edge cases
1 Like

Will there be a public repo for the code after that point? Or more specifically, will “issues” be tracked elsewhere than the forum?

Bah, should have a breakdown here (of major fixes at least).

Interesting. I don’t want to read too far into things, but this has biggish implications for the threading and/or “everything is a buffer” stuff?

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?

Hmm, if 0 is coming out, that would complicate things even if you are appending.

Is there a bug that’s returning 0 regardless, or is the first sample “triggering” an onset no matter what?

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…

I hope this helps. And that you will have fun.


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).

1 Like

also, you can be reassured that an offset will always be given (at the end of the file) if the slice is ‘on’ at that point.

1 Like

@tremblap Just one small thing - the bufampslice ref says its a spectral slicer in the digest :slight_smile:

1 Like

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…

1 Like

Ok, made a separate bug/issue thread for it.

Oh man, hoping I can go 3-for-3 in terms of finding alphaXXb-worthy bugs!

some bugs (like this one) are worthy of XXx releases in themselves. But do not dilute your work just to get x > a :wink: