Smoothing the output of fzero~ (when converting to MIDI)?

    Oct 02 2013 | 10:02 am
    I'm trying to build a device to convert mono melodies to MIDI notes using fzero~. The problem is that fzero~ outputs continuous flow of frequency data, which needs to be smoothed to be useable as MIDI notes.
    Here is my attempt to achieve this (see attached image and the code). Please, can you advice a better ways to convert the frequency flow to useable MIDI notes?
    Thank you!

    • Oct 02 2013 | 12:23 pm
      I didn't try this out, but it may help:
    • Oct 02 2013 | 1:29 pm
      Thank you for your help.
      It seems, we don't need an additional amplitude level check, as fzero~ outputs 0. as a frequency when there is no signal: so all of the 'empty' MIDI-notes are filtered at [if $i1 > 43 then $i1].
      There are great ideas in the smoother patcher. Unfortunately we can not use smth like [slide] as it introduces unwanted chromatic arpeggios. I will try to investigate further the [zl group] > [zl median] approach. This seems promising despite of the latency it introduces...
      There is another one approach. We can switch fzero~ to output a list (frequency and amplitude) instead of a Bang from it's right outlet when detecting onset. Theoretically detected onsets can be used as MIDI note triggers. But currently the list contains 0. as a frequency on 90% of detected onsets. Is this a bug and the frequency is outputted before it is really detected?
    • Oct 02 2013 | 11:30 pm
      to get around the 'arpeggio' artifact you could get the difference (delay and subtract, absolute value) between two adjacent analyses and if the jump is larger than a semitone you switch out the slide object (adds more latency)
      but i think there are more robust pitch detection strategies around -- i believe fiddle~ is the 3rd party external of choice. i think it uses sophisticated fft and cepstrum analysis to get a more 'perceptually' accurate result, and maybe has built-in smoothing algorithms...? worth checking out anyway
    • Oct 03 2013 | 12:21 am
      The onset detection in fzero~ can be triggered by amplitude changes, as well as pitch. So, there are cases where it reports that a note has happened before it has a good guess about what the pitch is.
      You could use the bang to open a gate, and then take the first non-zero pitch out the left outlet. Untested:
    • Oct 06 2013 | 2:05 pm
      I've done a lot of pitch tracking using fiddle~ and gbr.yin~ (FTM from IRCAM, which is GREAT but doesn't work with M4L), and just starting to look at fzero~. For M4L I will perhaps use yin~ for the time being or revert to fiddle~. Putting a "round" object between fzero~ and ftom is very important for me (violin) using any trackers. I will be looking into using analyze~ (CNMAT) to compare with the fzero~ tracking...
    • Oct 06 2013 | 5:20 pm
      Instead of with zl.median, try
      I've had good experiences with transcribe~ for piano.
    • Oct 06 2013 | 11:09 pm
      Instead of with zl.median, try
      yes, that's what I meant
    • Oct 07 2013 | 12:30 am
      @VK: Have you gone through the settings in the back tabs of the help file? I generally find that a bit of tweaking can really improve the results.
      What kind of signal are you trying to track?
    • Oct 07 2013 | 4:56 pm
      Any feedback about how people are using fzero~: settings tweaks, what works, what doesn't, &c. would be appreciated. That object is still relatively new, and I'm sure there are improvements that could be made.
    • Oct 07 2013 | 4:59 pm
      Another interesting smoothing approach is CNMAT's "look before you leap" object:
      It doesn't incur the latencies that a running average will.
    • Oct 07 2013 | 6:26 pm
      Have you gone through the settings in the back tabs of the help file? I generally find that a bit of tweaking can really improve the results.
      What kind of signal are you trying to track?
      This is a tenor-saxophone. Monophonic signal, harmonic-reech and not really stable at the pitch.
      Yes, I was experimenting with these without significant success. The pitch recognition seems good enough as a continuous data flow, but I'm still not able to quantize it to a valid MIDI notes...
    • Oct 08 2013 | 3:49 am
      Is this any better? worse?