Sounds like you know a thing or two about pitch detection... I've been working on a C implementation of YIN and PYIN (a real GPL minefield for someone wanting to provide the end result as MIT/public domain!), and am wondering if it's a good choice for real time, cpu-bound speech pitch detection, or if there's better ways. May I ask what your thoughts are on this?

Have you also considered implementing the Nebula[1] algorithm?

[1] https://github.com/Sleepwalking/nebula

I need non-GPL libraries as a reference. The problem with YIN and especially PYIN is that the MIT-code I've found sometimes looks a bit too similar to earlier code in GPL. Rewriting that into the same but in different code is fairly hard. Here I'm assuming that translating eg. GPL Python or C++ into C would mean the license is retained

Can you not just write it from the paper(s)? Or is that more effort than value to you?

> that translating eg. GPL Python or C++ into C would mean the license is retained

It depends a bit on what exactly "translating" means but you could easily be a derivative work.

Honestly in that situation I wouldn't even look at the code. You might use in to test equivalent behavior after you have your own implementation, but only in a gross sense.

I think I have to look at the code when using other people's MIT licensed code... If they have used something that's GPL or used someone else's code that turns out to be GPL, then it becomes my problem when translating it. And I'm not smart enough to just follow a paper

I have some code here if it interests you: https://github.com/sevagh/pitch-detection

My favorite is the McLeod Pitch Method/MPM. Runs fast enough for realtime purposes in a WASM example too: https://github.com/sevagh/pitchlite

Ha! I've translated your YIN code actually! Your autocorrelation is pretty cool - GPL versions all use an additional FFT. Have been struggling with your PYIN implementation because the beta distribution is copied from the GPL PYIN source, and the paper just references its source code for that part, and as you also found out, it's not a real beta distribution. I asked one of the PYIN authors (Dixon) if he were willing to change the license and he forwarded my mail a week ago - haven't heard back. Then there's the absolute_threshold function that is the same as in the PYIN source where it says "using Jorgen Six'es loop construct". This "loop construct" doesn't have a license, because he doesn't answer the issues about that in his TarsosDSP library, and I'm not sure if I should bother him about a few lines of code. I'm assuming it's a coincidence and that's just a normal way to find the absolute threshold. I really don't want to point fingers here, I'm being paranoid because I try to make sure I don't publish something that can put people in trouble...

So I have been staring at your code for many hours, and the YIN-implementation works well. The PYIN on the other hand.. well I necro posted a while ago in one of your pull requests I think ;)

It sounds like you’ve found it already but th original pYin implementation is in the VAMP plugin. Simon Dixon is my PhD supervisor but he’s quite busy. Feel free to email me questions in my the meantime. j.x.riley@ the same university as Simon. There’s also a Python implementation in the librosa library which might have a better license for your purposes.

Amazing! You are much more thorough about licensing issues than I am.

> And I'm not smart enough to just follow a paper

Don't sell yourself short. This is the sort of thing that is only straightforward if you have the right background.

Based on our current tests, our algorithm shows significantly higher accuracy and robustness compared to traditional digital signal algorithms such as PEF, NCF, YIN, HPS, etc. Our team is working diligently, and we will release benchmark test data and results in the near future.

That's pretty nice. Do you have any idea how it does it?

That's interesting. Can you point to one of these piano tuning apps that are $100+?