Chaining onset detectors (novelty -> ampslice)

Not really (more below).

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.

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

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:

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” @startframes 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.