Not sure if this is a bug or just a weird byproduct of how things work, but working with fluid.noveltyslice~ at the moment, and it seems like the loudness and pitch algorithms don’t respond (across a wide range of kernelsize / filtersize) or in the case of loudness when it does do something, it’s orders of magnitude less than any of the other algorithms.
I’ve been testing with some of my own material, but in checking the fluid.noveltyfeature~ helpfile (default audio example), there’s literally no response from the pitch algorithm at all (actually that’s not true, it seems to response to the change in silence when the loop repeats?), and loudness only registers the tiiiiniest blip (that’s impossible to threshold).
Is there some voodoo about novelty that I’m not understanding here or is there something odd going on under the hood with these algorithms?
it was always thus - hence my example code of an iterative way to ‘find’ a threshold given a number of slices. Also, don’t forget pitch is fragile to fft size so again this iterative approach was helpful to understand a (material dependant) threshold range…
Hmm, you would think the pitch algorithm would do something with the default @fftsettings 1024 -1 -1 for that @a.harker example. It seems to instead do literally nothing except response to the whatever changes at the loop point of the audio.
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. When I rescale the pitch channel internally, it behaves much (much) better. 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.