Chaining onset detectors (novelty -> ampslice)

[rodrigo.constanzo]

@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/

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.