# Chaining onset detectors (novelty -\> ampslice)

**URL:** https://discourse.flucoma.org/t/chaining-onset-detectors-novelty-ampslice/503
**Category:** Code Sharing
**Created:** [May 31, 2020, 12:26am UTC](https://discourse.flucoma.org/t/chaining-onset-detectors-novelty-ampslice/503 "2020-05-31T00:26:33Z")
**Posts on this page:** 1
**Showing post:** 7

<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: [January 5, 2024, 11:58am UTC](https://discourse.flucoma.org/t/chaining-onset-detectors-novelty-ampslice/503/7 "2024-01-05T11:58:50Z")

</div>

> [@tremblap](#):
>
> Is this solved?

Not really (more below).

> [@tremblap](#):
>
> q1: I love 9 as it does - it does a prediction of the future (like 6) in the complex domain (like 8) (works well for pitch material more than noise) then it sums the differences with the actual future but considers downward distance as important as upwards. I presume the output of onsetfeatures would show you that, so if unclear, let me know and I can try to make a didactic example.

Algorithm 9 does appear to be the most effective one across the board. Oddly enough on realtime audio I can never get it to work as well on varied material as I can with ampslice (even for non-drum sounds) but for offline stuff, it likely grabs more stuff than ampslice might on its own.

Having a more descriptive definition like this in the reference would be useful as algorithms 6-9 make little sense in terms of reading what it is doing.

> [@tremblap](#):
>
> q2: for window - check the ‘where is my data’ example in the other thread. You are right in theory, but you forget the windowing. if your click is at sample 1001 for instance, it’ll be mostly silenced by the windowing in that frame…

I did implement all the bits I was working on here:

> [@rodrigo.constanzo](#):
>
> If [`fluid.bufonsetslice~` → `fluid.bufampslice~`] returns a value, then search for a zero-crossing only _before_ the detected onset as `fluid.bufampslice~` is quite temporally accurate and I just want to add a kind of `@lookback` functionality to the detected onset position. In this case it would be a fairly small amount of samples (`~16 samples`).
> 
> If [`fluid.bufonsetslice~` → ~~fluid.bufampslice~~] then search for a zero-crossing only _after_ the detected onset from `fluid.bufonsetslice~` since it will, by definition, happen _after_ that point. In this case it would also be a fairly large amount of samples (`~256 samples`) and then picking the latest position if multiple zero crossings are detected since the temporal slop here would be intrinsically higher.

I forget the specifics of it, but I do a bunch of conditional stuff where I check either before and/or after the detected onset to refine the timing. Theoretically it’s a good idea and was working well for audio in which both onsets where found, but I started noticing that `fluid.bufampslice~` would never find an onset within the prescribed window… (I had conditional stuff where if ampslice didn’t find anything, it would default to the bufonsetslice timing).

All of this has come to a standstill because of this:  
[https://discourse.flucoma.org/t/fluid-bufampslice-not-working-correctly-when-using-numframes/](https://discourse.flucoma.org/t/fluid-bufampslice-not-working-correctly-when-using-numframes/)

At the moment, it’s actually possible to use `fluild.bufampslice~` as I mention above as it doesn’t work at all if using a different `@startframe` and/or `@numframes`, and actually never picks up the first onset in a buffer regardless (if the onset is as near the start of the audio file).

Unless I do some really wonky workaround where I set “fake” `@startframe`s thousands of samples before I’m actually interested in and `fluid.bufcompose~` fake audio to the start of a buffer in order to catch the onsets there, I can’t actually do any of this.

As I mention in the other thread, I suspect the envelope followers are starting from negative infinity and take a really long time to catch up, meaning that it’s not useful for the start of buffers, and not useful for any small/medium size `@numframes` because the envelopes never get into useful range.

It could be something other than that, but it definitely appears to be in bug territory here.

---

_[View the full topic](https://discourse.flucoma.org/t/chaining-onset-detectors-novelty-ampslice/503)._