Does your library have a transient detector?

[elanhickler]

Does your library have a transient detector? We need it for OTS plugin.

[RobinSchmidt]

i have rosic::OnsetDetector. i made this some time long ago for a beat detector for a dj software for another client, so it's perhaps not optimal for the purpose here (what is the exact purpose, actually?)

oh - and it uses float instead of double (because at the time, i programmed this outside the context of my library and just dragged in the code later). it would be straightforward to templatize it (and then drag it into rapt), though

[elanhickler]

To detect the start of a guitar pluck

[RobinSchmidt]

in what kind of sample? i assume, it can't be a one-shot guitar sample because then the transient is supposed to be at the beginning of the file anyway. so is it a sort of short phrase played on the guitar?

[RobinSchmidt]

the algorithm is based on this:

https://www.eecs.qmul.ac.uk/~simond/pub/2006/dafx.pdf

and in particular the "spectral-flux" measure (section 2.1). i also have some tweaks that weight low-frequencies stronger than high frequencies (seemed to suitable for full mixdowns - bassdrums are more important) - for guitar plucks, a stronger weighting toward high frequencies might be better.

i guess, i could also experiment with the other measures mentioned in the paper, so maybe it's more like a starting point. in the context of a full mixdown, i opted for spectral flux because there, the phase-information is probably useless anyway. but that might be a different story in this case

[elanhickler]

Hold off on continuing this discussion until further notice.

[elanhickler]

fail!

[RobinSchmidt]

you are throwing it at one-shot samples? that's not the kind of input, i was expecting. so it's not surprising to get bad results

[elanhickler]

ok a little more successful, I need you to create an algorithm based on Onset to work with single samples.

[elanhickler]

Is it helpful for this kind of algorithm to see multiple samples? does it not work as well for single samples?

[RobinSchmidt]

well, the algorithm was originally written to handle full mixdowns to mark the beats in a dj application (for syncing tracks, etc.) - so it expects a looong input file, chops it into blocks (size 1024 by default) with a "hop-size" of 128 (distance between (overlapping) block-starts). so this 128 hop-size defines the maximum time precision by which the transients can be detected (about 3 ms at 44.1). that's perhaps not precise enough for this case. also, one-shot samples are typically already cut at the beginning so maybe we should prepend some silence (otherwise, the first block may miss the transient due to windowing, etc.). also, it seems, the algorithm is faaar too sensitive for your signals (so many false positives). i think, there is a threshold somewhere in the algorithm which we should adjust (i.e. make adjustable from client code).

but maybe for such "simple" (monophonic, one-shot) samples, an entirely different approach based on the time-domain signal itself would be better. something based on the instantaneous envelope, maybe (which is totally useless in the case of a full mixdown - but in this case, it might be the way to go)

[RobinSchmidt]

something based on the instantaneous envelope

i'm talking about things like explained here:

https://www.gaussianwaves.com/2017/04/extracting-instantaneous-amplitude-phase-frequency-hilbert-transform/

the hilbert-transform is basically an allpass filter that phase-shifts all frequencies by the same 90°. applied to a sine-wave, it creates the corresponding cosine wave. the key is that - in contrast to you run-off-the mill allpass filter - it doesn't care about the sine's frequency. the regular allpass has a 90° phase shift only at one particular frequency and other shifts at other frequencies. the hilbert-filter has 90° shift at all frequencies. this can be also applied to a complex signal (a mix of frequencies). taking the absolute values (sqrt of the sum-of both squares) then gives what is called the "instantaneous envelope". i actually already have code for that. it's basically some mathy-fancy sort of envelope detector.

the article linked at the bottom, i just mark for later reading: https://www.ncbi.nlm.nih.gov/pmc/articles/PMC4003734/pdf/kja-18-1.pdf

[elanhickler]

the false positives are ok for now. they are low in strength and I can discard false positives that are not within "x window of time of the beginning of the sample"

I can feed it multiple samples at once but on the back end I know roughly where each sample starts and ends.

[elanhickler]

The first thing to do here would be to up the precision.

[elanhickler]

solved