[Lingot-devel] my recent development work on lingot

[Piotr Pawłow]

Hello,

I've been doing some development work on lingot recently for my employer. I 
thought you may be interested in some of the changes I've made.

We wanted a tuner application to add to our instruments. It had to be freely 
distributable, good looking, well working, preferably open source so we could 
tailor it to our requirements, and it had to work on Windows. After testing 
dozens of tuners, we have choosen Lingot as best looking and reasonably well 
working. Unfortunately there was no Windows version, so the porting effort 
began.

The result of this effort is available on http://lingot.gitara.org.pl/. The 
web site is currently only in polish, sorry. I'll do an english version when 
time permits. There is a download button at the top right, and an address of 
my SVN repository near the bottom of the page.

There are some important bug fixes in the repository, which you may like to 
apply to your version:

- at revision 300 - memory leak fix. Very important if you forget to close the 
program and leave it working for an hour or longer
- revision 310 and 312 - configuration saving fix for locales having character 
other than "." as the radix character.

Other changes:

- revision 292 - portaudio sound backend. Compile with CPPFLAGS=-DPORTAUDIO 
LDFLAGS=-lportaudio, as there is no configure switch to enable it yet. The 
portaudio backend is required for Windows and works well. On Linux I have a 
problem with it - it locks up on audio reinitialization (after changing 
preferences).

- revisions 292 to 295 - windows porting

- rev. 309, 311, 314 - alternative fundamental frequency estimator. Enable by 
putting "ESTIMATOR = 1" in the config file.

- rev. 296 - set default sampling rate to 44100. Seems to improve detection in 
some cases, but also seems to introduce more octave errors. Well supported by 
various sound cards. The old 8kHz default is a total disaster on my Linux 
box, as it chooses some completely different sampling rate, and give totally 
bogus results without any clue of what is happening.

- rev. 298 - polish translation. I had difficulties translating the advanced 
settings, and I tried to translate them according to how I think the program 
works, but I'm afraid it's probably way wrong :)

The rest is mostly my lame build script changes, our branding, SVN property 
changes etc.

About the estimator:

We found the original method of frequency estimation acceptable, however we 
are not satisfied with it. Some instruments require fiddling with settings as 
the program can't pick some strings on defaults. The settings are confusing 
and there are too many of them. Even after analyzing the source code, I can 
not tell what setting to change to improve note recognition in a particular 
case.

So I implemented the YIN estimator to see how well it will work. It is very 
simple and doesn't have many parameters to tune. I found it quite good. I 
seriously think about replacing the original estimator with YIN. 
Unfortunately the time domain version that I implemented has high CPU 
requirements. The frequency domain version should be much faster, but the 
math required is more complex and scares me a bit :)

I'd like your feedback about the estimator, how well it works for you. The YIN 
estimator likes high sampling frequencies, as with higher frequency it can 
get better match, but CPU requirements rise exponentially with the number of 
samples so be careful not to set it too high.

That's all, sorry for such a long post.

Cheers