Thanks! I've created a git repo containing relevant code snippets from this video, which is available at github.com/NValsted/VForScienceProjects. The snippets displayed in the video are not optimized for speed, and especially not the CMNDF. Memoizing this function (and thus avoiding multiple identical calls to DF) will greatly speed up the computation time, yet it is still too slow for real time input (a crude implementation of this is included in the code snippets in the git repo). Implementing it in a faster language than python along with some micro-optimizations will probably be sufficient, but it might be better to take a different approach, perhaps using spectral-domain methods like the fast fourier transform.

​@@vforscience3687 I took some YIN implementation made in Go, and it's almost real-time. I created a Synthesia-like game based on it: kzfaq.info/get/bejne/Y5-ff7ekxqfTeYE.html I use buffers of size 5512 samples and sample rate of 188200 (chosen randomly, now I wonder if my microphone could handle that or it increases sample rate by interpolation). This gives ~34 pitch measures per second, seems to be enough for the gameplay. Still, it will probably benefit from me learning more about DSP and tuning it better.

Hey! Thanks for reaching out, that sounds awesome! If you're familiar with GitHub, I'd recommend opening a pull request against this repository with the improved code github.com/NValsted/VForScienceProjects/tree/master/YIN_pitch_detection - Otherwise feel free to modify and share your code in any way you like :)

@@vforscience3687 Thanks for the reply! I've created the PR with the implemented changes and some comments about them. I hope you find them useful and interesting. Feel free to reach out with any comments!

Thanks! The animations are made with the community maintained version of a tool called Manim, which can be found at www.manim.community/

Glad you enjoyed it! I'm not particularly familiar with polyphonic pitch detection (PD) methods yet, but as far as I know, the fact that we do not necessarily know beforehand, how many pitches are present in a signal, and that pitch is not well-defined (in comparison to a frequency component) tend to be what makes polyphonic PD very difficult. In contrast, for monophonic PD, we generally make the assumption that one and only one pitch is present, so the problem is essentially reduced to guessing which single frequency is the most probable. From what I've seen, various polyphonic PD methods try to overcome this with some variation of detecting the most probable frequency, then either eagerly or lazily removing it along with its harmonics from the search space such that the next-most probable frequency will be detected and so on until some cutoff. I believe polyphonic PD is widely regarded as unsolved, but I would like to delve deeper into some of the current methods, possibly resulting in an explainer-video on the topic.

@@vforscience3687 Why, thank you! This is the longest and kindest reply I ever received from a KZfaqr. You are the best!

I'll try to explain by example. Recall that the value of the frequency we guess is (sample_rate / number_of_samples_shifted_at_best_guess). If we set the sample rate to 100, and we check lag values between 4 and 20, then the highest frequency we can guess is 100/4=25, and the lowest is 100/20=5. As long as we are limiting ourselves to lag values between 4 and 20, we will never guess frequencies outside the interval [5;25]. And in general, the interval of frequencies we consider is [sample_rate / upper_bound ; sample_rate / lower_bound]

This is a very silly mistake on my part. It is correct that you don't hear the same pitch, as the two notes are actually an octave apart.

It is available here github.com/NValsted/VForScienceProjects/tree/master/YIN_pitch_detection

Thanks, that's very generous of you! However, at the time of writing, I do not have any means of accepting donations. For the time being, I would recommend sponsoring some of the great, free open source tools, which many projects like this one depend on. I am sure a contribution to NumPy and the Python science ecosystem or Manim and its community will be well-received, and will also benefit those using such tools.