# Best buf-based slicer for keeping track of onsets \*and\* offsets?

**URL:** https://discourse.flucoma.org/t/best-buf-based-slicer-for-keeping-track-of-onsets-and-offsets/1435
**Category:** Usage Questions
**Created:** [May 2, 2022, 2:54pm UTC](https://discourse.flucoma.org/t/best-buf-based-slicer-for-keeping-track-of-onsets-and-offsets/1435 "2022-05-02T14:54:21Z")
**Posts on this page:** 11
**Page:** 1

<div class="post-metadata">

### Author: ![rodrigo.constanzo](https://discourse.flucoma.org/user_avatar/discourse.flucoma.org/rodrigo.constanzo/32/12_2.png) [@rodrigo.constanzo](https://discourse.flucoma.org/u/rodrigo.constanzo)
#### Post date: [May 2, 2022, 2:54pm UTC](https://discourse.flucoma.org/t/best-buf-based-slicer-for-keeping-track-of-onsets-and-offsets/1435/1 "2022-05-02T14:54:21Z")

</div>

So I’m starting to work on a slicer/juggler thing that will be built around the idea of taking incoming audio (in a long rolling buffer) and segment it based on some criteria, then play back a sequence/pattern of the events that are found.

Simple enough, but what I’m not sure about is which of the `...buf...~`-based slicers would give me good segmentation, critically including the _offsets_. Ideally I’d want to isolate “notes”/“events” that may be spaced out in time, so treating the time between slices as the whole segment isn’t ideal here.

I was thinking of using `fluid.bufnoveltyslice~` as the core slicer, as I’d like the segmentation to be fairly robust across a range of material, and perhaps chasing that up with `fluid.ampslice~` to find more precise boundaries, but neither of those spits out an offset. Presumably `fluid.ampslice~` knows what its internal “offset” is due to the hysteresis algorithm, but I can only access that with `fluid.bufampfeature~`, which I could then re-threshold to find onsets/offsets(?).

There’s `fluid.ampgate~`, but having absolute thresholding makes that pretty useless for arbitrary input.

Looking at `fluid.bufnoveltyfeature~` there’s a curve output, but I guess the algorithm has more of a big spike where novelty is detected, with little taper afterwards.

I guess I could do some parallel analysis and determine what “offsets” are in a different way, but this seems like something that should be a solved problem, or at least, solved ways of approaching the problem.

Any thoughts/suggestions?

---

<div class="post-metadata">

### Author: ![weefuzzy](https://discourse.flucoma.org/user_avatar/discourse.flucoma.org/weefuzzy/32/362_2.png) [@weefuzzy](https://discourse.flucoma.org/u/weefuzzy)
#### Post date: [May 2, 2022, 8:32pm UTC](https://discourse.flucoma.org/t/best-buf-based-slicer-for-keeping-track-of-onsets-and-offsets/1435/2 "2022-05-02T20:32:41Z")

</div>

Very much an unsolved problem! I think you’re right that a mixture of approaches would be the way to go. Perhaps a combination of the novelty feature and amp feature (which is the one from ampslice~), and maybe _also_ ampgate as a last resort…

---

<div class="post-metadata">

### Author: ![tremblap](https://discourse.flucoma.org/user_avatar/discourse.flucoma.org/tremblap/32/5_2.png) [@tremblap](https://discourse.flucoma.org/u/tremblap)
#### Post date: [May 2, 2022, 9:10pm UTC](https://discourse.flucoma.org/t/best-buf-based-slicer-for-keeping-track-of-onsets-and-offsets/1435/3 "2022-05-02T21:10:00Z")

</div>

2 passes with the 2nd being ampgate with threshold set relative to the overall loudness of a slice?

so many interesting ways to go about depending on the actual sounds and applications!

---

<div class="post-metadata">

### Author: ![rodrigo.constanzo](https://discourse.flucoma.org/user_avatar/discourse.flucoma.org/rodrigo.constanzo/32/12_2.png) [@rodrigo.constanzo](https://discourse.flucoma.org/u/rodrigo.constanzo)
#### Post date: [May 5, 2022, 12:22pm UTC](https://discourse.flucoma.org/t/best-buf-based-slicer-for-keeping-track-of-onsets-and-offsets/1435/4 "2022-05-05T12:22:46Z")

</div>

Hmm, I would have thought that “segmentation” took this kind of stuff into account, but I guess the expectation is more to have things be done butt-to-butt.

Having to make multiple passes isn’t the end of the world, it’s just a matter of trying to assess the same criteria on both ends. I guess what’s good about novelty is that it looks at stuff _other_ than just loudness, so to use that for the “onset” and then loudness for the “offset” could lead to odd edge cases.

I’ve not really played with novelty enough to know what tweaking all the parameters meaningfully does, but is it always so “spike”-y like in the help file? I would have imagined/pictured something more like an envelope follower-esque curve where it rides around a bit, where I can then set some schmitt trigger thresholding to get the start _and_ end of points of novelty (with perhaps a separate `fluid.ampslice~` step aftwards anyways to get the timing (potentially) more precise).

---

<div class="post-metadata">

### Author: ![weefuzzy](https://discourse.flucoma.org/user_avatar/discourse.flucoma.org/weefuzzy/32/362_2.png) [@weefuzzy](https://discourse.flucoma.org/u/weefuzzy)
#### Post date: [May 5, 2022, 3:50pm UTC](https://discourse.flucoma.org/t/best-buf-based-slicer-for-keeping-track-of-onsets-and-offsets/1435/5 "2022-05-05T15:50:07Z")

</div>

> [@rodrigo.constanzo](#):
>
> Hmm, I would have thought that “segmentation” took this kind of stuff into account, but I guess the expectation is more to have things be done butt-to-butt.

Audio DSP has solved fewer problems than you might think. But this is also one reason I prefer ‘slicing’ to ‘segmentation’. Basically, the whole notion of detecting the end of a sound is just much trickier. For one thing, it’s not especially clear that there’s an obvious perceptual mechanism to try and mimic: I don’t think we’re often terribly alert to the moment when a sound stops, unless we’re concentrating on that particular thing.

> [@rodrigo.constanzo](#):
>
> I’ve not really played with novelty enough to know what tweaking all the parameters meaningfully does, but is it always so “spike”-y like in the help file?

IIRC the help file uses quite a small kernel size so that the time scales are pretty short, hence spiky. The bigger you make the kernel, the smoother the curve (but greater the latency). Novelty slice uses a pretty simple peak picker, just looking for inflection points where a sample is greater than either of its neighbours, which is basically `[zl stream 3] -> [expr ...`. Offhand I don’t know what a _minima_ in the novelty curve might denote, offset-wise, but it might be useful as a switch type of thing to start then looking for when the signal amplitude goes below some point.

---

<div class="post-metadata">

### Author: ![jaseknighter](https://discourse.flucoma.org/letter_avatar_proxy/v4/letter/j/d2c977/32.png) [@jaseknighter](https://discourse.flucoma.org/u/jaseknighter)
#### Post date: [June 7, 2024, 7:12pm UTC](https://discourse.flucoma.org/t/best-buf-based-slicer-for-keeping-track-of-onsets-and-offsets/1435/6 "2024-06-07T19:12:01Z")

</div>

resurrecting this thread…i’m curious if any progress was made slicing offsets.

---

<div class="post-metadata">

### Author: ![rodrigo.constanzo](https://discourse.flucoma.org/user_avatar/discourse.flucoma.org/rodrigo.constanzo/32/12_2.png) [@rodrigo.constanzo](https://discourse.flucoma.org/u/rodrigo.constanzo)
#### Post date: [June 7, 2024, 8:35pm UTC](https://discourse.flucoma.org/t/best-buf-based-slicer-for-keeping-track-of-onsets-and-offsets/1435/7 "2024-06-07T20:35:54Z")

</div>

No not really, though it would be interesting. Would make for a kind of funky dataset where you’d then have “dead space” between the offset and the next onset.

There is a `fluid.bufampfeature~` (which may not have existed a few years ago?) which would mirror what I do for realtime stuff, by manually doing the thresholding afterwards, but not entirely sure how that would work for non-realtime stuff (e.g. buffer-based).

---

<div class="post-metadata">

### Author: ![jaseknighter](https://discourse.flucoma.org/letter_avatar_proxy/v4/letter/j/d2c977/32.png) [@jaseknighter](https://discourse.flucoma.org/u/jaseknighter)
#### Post date: [June 7, 2024, 9:03pm UTC](https://discourse.flucoma.org/t/best-buf-based-slicer-for-keeping-track-of-onsets-and-offsets/1435/8 "2024-06-07T21:03:34Z")

</div>

i was thinking actually about this to be able to play just the audio that isn’t involved with the start of a sound. 🙂

thanks for the reference to `FluidBufAmpFeature`. looking at the graph generated by the helpfile example, it seems like some analysis of the buffer it generates (see blue lines in attached) could help approximate the offset location.

 ![image](https://discourse.flucoma.org/uploads/default/original/2X/5/5a22fa70ed8176e3013b7d5635e69f6094617d62.jpeg)

---

<div class="post-metadata">

### Author: ![rodrigo.constanzo](https://discourse.flucoma.org/user_avatar/discourse.flucoma.org/rodrigo.constanzo/32/12_2.png) [@rodrigo.constanzo](https://discourse.flucoma.org/u/rodrigo.constanzo)
#### Post date: [June 8, 2024, 11:44am UTC](https://discourse.flucoma.org/t/best-buf-based-slicer-for-keeping-track-of-onsets-and-offsets/1435/9 "2024-06-08T11:44:09Z")

</div>

That’s the line to use, it’s just a matter of crawling through the samples to find where it goes _below_ a specified threshold. I imagine in SC this is easier as you can just setup a for loop and walk through the buffer based on whatever your minimum onset size is or whatever metric you want to use.

---

<div class="post-metadata">

### Author: ![jaseknighter](https://discourse.flucoma.org/letter_avatar_proxy/v4/letter/j/d2c977/32.png) [@jaseknighter](https://discourse.flucoma.org/u/jaseknighter)
#### Post date: [June 8, 2024, 3:43pm UTC](https://discourse.flucoma.org/t/best-buf-based-slicer-for-keeping-track-of-onsets-and-offsets/1435/10 "2024-06-08T15:43:12Z")

</div>

i was also thinking if I reversed the buffer for each slice and reran onset detection on the reversed slices, i might be able to use the onsets of the reversed slices as the offsets i am looking for. i will try this and see what happens.

---

<div class="post-metadata">

### Author: ![rodrigo.constanzo](https://discourse.flucoma.org/user_avatar/discourse.flucoma.org/rodrigo.constanzo/32/12_2.png) [@rodrigo.constanzo](https://discourse.flucoma.org/u/rodrigo.constanzo)
#### Post date: [June 8, 2024, 4:40pm UTC](https://discourse.flucoma.org/t/best-buf-based-slicer-for-keeping-track-of-onsets-and-offsets/1435/11 "2024-06-08T16:40:33Z")

</div>

Hmm, that would theoretically give you some different values, but it would definitely be different from what you get from `ampgate` processes (i.e. the “off” of a Schmitt trigger threshold).

Would also be quite variable on the source sounds (perhaps a good thing?). Curious your results!
