looking at frequency values from mtof I see a lot of jumping even with no/very low input. I would like to suppress these transients with a moving average filter, it isn't clear to me how I'd do this. A low pass filter also might work but trying lop~ says I can't connect signal outlets to control inlets . I honestly think moving average is best for my use case (haptic pitch tracking) as I'd like a smooth rise and fall in pitch .Any suggestions ?

@vulturev1 You could play with the -stabletime switch for [simund~] .... that might help

You can use [line~] to send control rate data into [lop~].... https://forum.pdpatchrepo.info/topic/11850/explanation-for-lop-object-in-this-patch-requested
If you can use the audio output from [lop~] that is best. Otherwise, unfortunately you will need to use [metro] and [snapshot~] to get back to control rate data.
I don't think there is another way, but I am not up to date with recent objects.
David.

@whale-av

Thanks for the reply, not sure I can use data directly from lop since I need to put that into an oscillator before DAC. I'm also confused how the line~ object makes the input into lop acceptable. But it still leaves me with another problem, sometimes pitch detection drops even when there is pitch, a moving average would solve both of these issues for me, if I could put a few samples from mtof into a buffer constantly and take the average to feed to osc

@vulturev1 You will need to play around with arguments to get what you need..... try.pd
David.

@whale-av Just to follow up on that try patch....

[line~] produces audio output from control rate input.... that is why it is necessary.... but other objects do the same..... [phasor~] and [osc~] being examples.

The original data jumps.... square wave.
[line~] then produces straight line triangles..... slopes...
[lop~] turns the slopes into curves.
[snapshot~] then samples the curve value and produces discreet values at a specific time.

So you need [line~] to feed data to [lop~] but [lop~] is not doing much if it does not have the time to produce a curve so maybe is unnecessary..... or give it the time.

[Snapshot~] is a bit expensive when running fast.

You probably need a mechanism to recognise a genuine new note if timing is important, although timing accuracy might be difficult as the data would need to be delayed for confirmation.
You or I or someone else might have ideas about how to do that
David.

@vulturev1 The external library "else" has mov.avg (OF COURSE it does! ). That said, my intuition would be to try it @whale-av's way first.

@vulturev1 Processing the input can help a great deal with [sigmund~] jumping around but how to best go about this depends on what your input is and what you want on the output. When I was using [sigmund~] a lot I found filtering, frequency multiplication and compression all to be useful for getting stable output, especially frequency multiplication. I always found it easier to address the problem on the input instead of the output.

@vulturev1 Use the right outlet of [sigmund~] with [>] and [spigot] to filter out "silence".
Look at [moses], you can use it to filter big jumps. Maybe use feedback to dynamically adapt the right inlet.
Also play with sigmunds window-size and hop-size.

This is a Vanilla moving average (EDIT now with [arraysum]) :

movingaverage3.pd
movingaverage3-help.pd
Moving average is a low pass and it also distorts the good data portion.
Reading your description, maybe a median filter with uneven windowsize is better suited, see this screenshot, made with else/median: https://forum.pdpatchrepo.info/topic/13849/how-to-smoothe-out-arrays/11

EDIT: Pd 0.54 Also study helpfile with -minpower, -quality, tracks ect !

[moses], you can use it to filter big jumps. Maybe use feedback to dynamically adapt the right inlet.

moving-windowed-gate.pd
moving-windowed-gate-help.pd
(edit:small bug fix)