Valery_Kondakoff

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?

smoothing-the-output-of-fzero-when-converting-to-midi

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?

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 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?


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

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: 

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: 


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...

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...


Instead of zl.group with zl.median, try zl.stream.

I've had good experiences with transcribe~ for piano.

@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?

@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?


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.

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.


Another interesting smoothing approach is CNMAT's "look before you leap" object:

It doesn't incur the latencies that a running average will.

Another interesting smoothing approach is CNMAT's "look before you leap" object:
http://cnmat.berkeley.edu/patch/4067

It doesn't incur the latencies that a running average will.


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.

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...

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?

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...


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