# Onset detection that focuses on \*pitch\*?
**URL:** https://discourse.flucoma.org/t/onset-detection-that-focuses-on-pitch/2607
**Category:** Usage Questions
**Created:** [July 4, 2025, 1:35pm UTC](https://discourse.flucoma.org/t/onset-detection-that-focuses-on-pitch/2607 "2025-07-04T13:35:42Z")
**Posts on this page:** 13
**Page:** 1
### Author:  [@rodrigo.constanzo](https://discourse.flucoma.org/u/rodrigo.constanzo)
#### Post date: [July 4, 2025, 1:35pm UTC](https://discourse.flucoma.org/t/onset-detection-that-focuses-on-pitch/2607/1 "2025-07-04T13:35:43Z")
So at the moment I’m working on some stuff with a melodica, and I’m having a really hard time with all of the onset detection algorithms (ampslice works, but is erratic, onset isn’t much better, and novelty has a weird issue (more below)).
Ideally I’d want to have an onset detected when a new _pitch_ is detected. As far as I can tell, this is only explicitly available in `fluid.noveltyslice~` with the pitch algorithm (`@algorithm 3`)).
Sadly there’s some `fluid.noveltyfeature~` plumbing that normalizes pitch/confidence in a way that is inseparable (as outlined in [this thread](https://discourse.flucoma.org/t/fluid-noveltyslice-loudness-and-pitch-algorithms-busted/1671)).
Specifically this bit:
> [@Fluid.noveltyslice~ loudness and pitch algorithms busted?](https://discourse.flucoma.org/t/fluid-noveltyslice-loudness-and-pitch-algorithms-busted/1671/10):
>
> It is moving, but so minutely I had to attach a debugger to confirm 🙄 For pitch I think the problem here is that when it was thrown into Novelty we didn’t pause to think that the two dimensions are radically different scales, so the pitch output completely swamps the confidence in the similarity calculation.
>
> In that oboe example, the jumps in confidence are pretty important as marking the transition between those otherwise quite stable multi-phonics.
I initially thought about bumping that thread to see if @weefuzzy had a chance to:
> [@Fluid.noveltyslice~ loudness and pitch algorithms busted?](https://discourse.flucoma.org/t/fluid-noveltyslice-loudness-and-pitch-algorithms-busted/1671/10):
>
> I’ll push that change in due course.
>
> There’s a constant offset to the novelty output as well, which isn’t making me happy.
But as a broader concept, I figured it was worth making a ‘best practice’ inquiry.
For context, here’s a bit of the kind of audio I’m working with:
[shortexample.wav.zip](https://discourse.flucoma.org/uploads/short-url/bqvkFnpyNka0qSeWj0EvXI5n8li.zip) (1.5 MB)
There’s a few moments with large amplitude changes corresponding with notes, but there’s a kind of weird offset in the audio that corresponds with those moments which often makes the amplitude differential go _down_ when an onset happens, rather than up.
But short of an updated `fluid.noveltyfeature~`, what would be a good way to determine onsets with changes in pitch?
And/or is there a reason that there isn’t a pitch-based algorithm available on `fluid.onsetslice~`/`fluid.onsetfeature~`?
Lastly, while wrapping up this post, I was reminded of the [Hz](https://github.com/cycfi/hz_audio_to_midi) algorithm, which I posted about [here](https://discourse.flucoma.org/t/hz-pitch-detection-algorithm/2574). I’ve not tested that out yet, nor messed with any pre-processing of the melodica signal either, which would probably help.
---
### Author:  [@tremblap](https://discourse.flucoma.org/u/tremblap)
#### Post date: [July 6, 2025, 10:38am UTC](https://discourse.flucoma.org/t/onset-detection-that-focuses-on-pitch/2607/2 "2025-07-06T10:38:05Z")
> [@rodrigo.constanzo](#):
>
> Ideally I’d want to have an onset detected when a new _pitch_ is detected. As far as I can tell, this is only explicitly available in `fluid.noveltyslice~` with the pitch algorithm (`@algorithm 3`)).
quickly because I’m running between things, but I’ve had good results using chroma in novelty on the bass.
more soon
---
### Author:  [@rodrigo.constanzo](https://discourse.flucoma.org/u/rodrigo.constanzo)
#### Post date: [July 6, 2025, 12:07pm UTC](https://discourse.flucoma.org/t/onset-detection-that-focuses-on-pitch/2607/3 "2025-07-06T12:07:22Z")
That does look better overall as chroma is intrinsically “normalized”.
re:latency, is there a difference between `fluid.noveltyslice~` and `fluid.onsetslice~` with comparable fft sizes? In my mind novelty is always “slow”, but that could just be because of how I’ve seen it used.
And/or is it possible to take the output of `fluid.chroma~` and manually compute a difference in consecutive frames (ala what `fluid.onsetslice~` is doing for the spectral features).
---
### Author:  [@tremblap](https://discourse.flucoma.org/u/tremblap)
#### Post date: [July 6, 2025, 12:22pm UTC](https://discourse.flucoma.org/t/onset-detection-that-focuses-on-pitch/2607/4 "2025-07-06T12:22:09Z")
> [@rodrigo.constanzo](#):
>
> re:latency, is there a difference between `fluid.noveltyslice~` and `fluid.onsetslice~` with comparable fft sizes?
there is - there is even a parameter that tells you 😃 - in effect you need the kernel size to ‘compare’ a local similarity/novelty.
out of chroma~ and manual difference is a possibilty to explore, you can do it with a sort of weighted average (aka centroid) I reckon. but then why not use pitch~…
share along your experiments.
p
---
### Author:  [@rodrigo.constanzo](https://discourse.flucoma.org/u/rodrigo.constanzo)
#### Post date: [July 6, 2025, 12:35pm UTC](https://discourse.flucoma.org/t/onset-detection-that-focuses-on-pitch/2607/5 "2025-07-06T12:35:56Z")
> [@tremblap](#):
>
> there is - there is even a parameter that tells you 😃 - in effect you need the kernel size to ‘compare’ a local similarity/novelty.
I know they report latency, but I’m not entirely sure what “novelty” vs “difference” means, in a temporal domain.
> [@tremblap](#):
>
> but then why not use pitch~…
Because it’s “[broken](https://discourse.flucoma.org/t/fluid-noveltyslice-loudness-and-pitch-algorithms-busted/1671/10)” (i.e. normalized pitch and confidence means it response very poorly in context).
> [@tremblap](#):
>
> share along your experiments.
For now I’m still using ampslice and just dealing with the weirdness, but it’s not ideal for general use cases.
---
### Author:  [@tremblap](https://discourse.flucoma.org/u/tremblap)
#### Post date: [July 6, 2025, 12:40pm UTC](https://discourse.flucoma.org/t/onset-detection-that-focuses-on-pitch/2607/6 "2025-07-06T12:40:06Z")
> [@rodrigo.constanzo](#):
>
> Because it’s “[broken](https://discourse.flucoma.org/t/fluid-noveltyslice-loudness-and-pitch-algorithms-busted/1671/10)” (i.e. normalized pitch and confidence means it response very poorly in context).
I mean fluid.pitch~ instead of fluid.chroma~ that you proposed to use instead of novelty.
---
### Author:  [@tremblap](https://discourse.flucoma.org/u/tremblap)
#### Post date: [July 6, 2025, 12:40pm UTC](https://discourse.flucoma.org/t/onset-detection-that-focuses-on-pitch/2607/7 "2025-07-06T12:40:48Z")
> [@rodrigo.constanzo](#):
>
> it’s not ideal for general use cases.
I thought that by now, you would have stopped in ‘general use cases’ 😃 - there is no such a thing
---
### Author:  [@tremblap](https://discourse.flucoma.org/u/tremblap)
#### Post date: [July 6, 2025, 12:45pm UTC](https://discourse.flucoma.org/t/onset-detection-that-focuses-on-pitch/2607/8 "2025-07-06T12:45:39Z")
> [@rodrigo.constanzo](#):
>
> “novelty” vs “difference” means,
learn.flucoma has a good reference for both 🙂 novelty is this idea that you create local similarity matrices (a context, the kernel size) then you check if how the new frame is deference to that context. difference is now vs just before, and in onset, it is made for onset, so looking for various assuptions in spectrum of what an attack is: whiter spectrum than the frame before, in various flavours.
---
### Author:  [@yogi](https://discourse.flucoma.org/u/yogi)
#### Post date: [July 6, 2025, 1:33pm UTC](https://discourse.flucoma.org/t/onset-detection-that-focuses-on-pitch/2607/9 "2025-07-06T13:33:31Z")
Hello, wouldn’t using fluid.onsetslice on the output of fluid.pitch work in this case?
---
### Author:  [@rodrigo.constanzo](https://discourse.flucoma.org/u/rodrigo.constanzo)
#### Post date: [July 6, 2025, 1:47pm UTC](https://discourse.flucoma.org/t/onset-detection-that-focuses-on-pitch/2607/10 "2025-07-06T13:47:31Z")
> [@tremblap](#):
>
> I mean fluid.pitch~ instead of fluid.chroma~ that you proposed to use instead of novelty.
Ah right. I guess some difference computation on the confidence would be indicative of something, but not entirely sure that on it’s own that would be enough (e.g. a single sustained note glissing won’t vary in confidence much I would think).
> [@tremblap](#):
>
> I thought that by now, you would have stopped in ‘general use cases’ 😃 - there is no such a thing
Well, one part is I’m working on a video/teaser idea where I’m using melodica, so for the purposes of this video, I’m just going with ampslice, but being able to segment by pitch is something that I think would be good to optimize.
> [@tremblap](#):
>
> learn.flucoma has a good reference for both 🙂 novelty is this idea that you create local similarity matrices (a context, the kernel size) then you check if how the new frame is deference to that context. difference is now vs just before, and in onset, it is made for onset, so looking for various assuptions in spectrum of what an attack is: whiter spectrum than the frame before, in various flavours.
In that case, I suppose novelty is the better choice here since it would be better suited to a broader/varied difference. The thresholding just makes it near impossible to use (pitch/loudness have near 0 values for just about all material (pitch in particular is awful)).
> [@yogi](#):
>
> Hello, wouldn’t using fluid.onsetslice on the output of fluid.pitch work in this case?
In this case I’m more interested in determining that a “change in pitch” has happened at all, and `fluid.onsetslice~` does a really poor job of it anyways. I spent a bit of time tweaking the settings and trying different algorithms, but none of them worked even remotely.
To be fair, I think that the melodica audio is particularly problematic for some reason, so I imagine some aggressive pre-processing is in order, but I would assume that something would be able to work even a little.
---
### Author:  [@tremblap](https://discourse.flucoma.org/u/tremblap)
#### Post date: [July 6, 2025, 7:03pm UTC](https://discourse.flucoma.org/t/onset-detection-that-focuses-on-pitch/2607/11 "2025-07-06T19:03:20Z")
> [@yogi](#):
>
> Hello, wouldn’t using fluid.onsetslice on the output of fluid.pitch work in this case?
we cannot yet do non-fft… but doing ampslice (detrending) could be a fun experiment. just remove the filter and it should work (famous last words)
---
### Author:  [@yogi](https://discourse.flucoma.org/u/yogi)
#### Post date: [July 9, 2025, 8:04am UTC](https://discourse.flucoma.org/t/onset-detection-that-focuses-on-pitch/2607/12 "2025-07-09T08:04:02Z")
Oops , I meant ampslice yes, then I find it a bit tricky to convert pitch to db.
---
### Author:  [@tremblap](https://discourse.flucoma.org/u/tremblap)
#### Post date: [July 9, 2025, 9:04am UTC](https://discourse.flucoma.org/t/onset-detection-that-focuses-on-pitch/2607/13 "2025-07-09T09:04:04Z")
db is log, so you can run it on midicents output (also log) and that might help 🙂