Novelty feature cryptic behavior

Usage Questions
1

I am currently doing some tests with novelty feature and I am getting very unexpected values.
If I analyze a simple sinewave with any algorithm I get a output of 0.3319… from my understanding of the object the output should be something close to 0.
If I modulate greatly the amplitude of the sinwave and then use the loudness algorithm the value moves veeeeery slightly but the bias of 0.3319 remains there.
Even in the examples using the samples (I am testing on supercollider) it looks like the values gets stuck around 0.33191 for most of the time

2

Hello

This works for me here, does it make sense to you (the X mouse is to chose between various feature on which it is detecting the novelty)

{FluidNoveltyFeature.kr(SinOsc.ar(LFNoise0.kr(10).exprange(100,1000)),MouseX.kr(0,4.1).round.poll(1)).poll(10)}.scope
3

and even more interesting, this example. The MFCC changes a lot from sine to noise and noise to sine. I’ve smoothed the output so we can capture the peak and you can see that during sine, stable change (the natural wiggle of fft process) then during pink it is wiggly, but not as much as when we change from one to the other.

{var in = Select.ar(LFPulse.ar(0.5,mul: 0.5, add: 0.5),[PinkNoise.ar(0.1),SinOsc.ar(110,mul: 0.2)]);FluidNoveltyFeature.kr(in,1).lagud(0.001,0.5).poll(20);in}.play

Then you can play with your signal, what you care about, and how big a kernel (how wider is the ‘present’ to check for changes) and how to smooth it (the filter size) and then you have fun!

I hope this helps

p.

1 Like
4

I tried some more tweaking to grasp how this works… This is an example with the pitch feature. Would it be helpful to add some more examples in the docs?

({var in = SinOsc.ar(LFNoise0.kr(3).exprange(100,1000).lag(0.01)); 
var value = FluidNoveltyFeature.kr(in,3,10,10,512); 
	Out.kr(2, (value*10).lag(0.2)); // look at the scope channel 3 control
	Out.ar(0,in);
}.play;)

What is confusing for me is how this is then used in the Novelty Slice. My guess was that the output of the feature was compared to the threshold and then it gives an impulse every time it was over the threshold

5

Hi Nesso,

Sorry to be slow to get back. In order

  1. Yes, will small kernel sizes you will see a noticeable constant offset in the feature level, and (depending on the feature) very small movements around that indeed. I can, in fact, make the offset go away by using a slightly different kernel design, but I need to test if that has unforeseen effects before promising that
  2. The peak detection in the slicer works by looking for local maxima (points bigger than either neighbour) that are also above the threshold. The code in question is here: flucoma-core/NoveltySegmentation.hpp at 60e1a775c55aed5aa7db6b700331ceb52d7e7f3b · flucoma/flucoma-core · GitHub
1 Like