Just found out that the tuner in the current release is quite wrong. It is about 3,5% sharp. Can verify it with the TC internal amp tuner and the Korg Pitchblack tuner and of course with the ears. 3,5% is a lot! I am using an acoustic bass with piezo pickup.
Is there a configurable offset somewhere?
My system version is 22.214.171.12456 - should be up-to-date
i’ve just put the Invada Test Tones plugin on a pedalboard, and routed the Dwarf output back to the input, to test the tuner. here’s what i see:
55.16 Hz reads 0.80 C
55.12 Hz reads 0.60 C
55.08 Hz reads 0.40 C
55.04 Hz reads 0.20 C
55.00 Hz reads 0.01 C
54.96 Hz reads -0.20 C
54.92 Hz reads -0.40 C
54.88 Hz reads -0.60 C
54.84 Hz reads -0.80 C
…so that all starts to look predictable, but neither like what @rocavaco sees, nor like what it should be.
If the tuner is made for real musical instruments then, it should process a signal twice:
Estimating intonation offset of the entire signal (fundamental freq + harmonics)
Filtering the signal to find its fundamental frequency
Is it possible that the tuner correctly detects the fundamental frequency (54,96 Hz; as shown when testing with pure sine wave tones), but calculates cents deviation from the whole harmonic content, thus showing a different value?
Could be an error in evaluating the harmonic content (bass string partials).
The tuner consists of multiple parts on the mod. The base is the pitch tracker. It detect the frequency and hand that over to the mod-ui. And only the frequency. So, does the pitch tracker track the correct frequency or not? It seems it does, even in the worst example you show above.
Cent calculation is then done in the mod-ui in a python script. Only the detected frequency value and the reference frequency value been known there, no other harmonics, from this point on it is plain math.
This is the python script doing this job:
I just rechecked the math and it is correct. feeding the script with a frequency of 54.96 returns -1.2595373775411645 which is absolute correct. And it returns the correct values for regardless what I feed in.
However, the python script hand over the detected frequency, the note name, the octave and the cent value to the mod controller. The mod controller does nothing more then convert this values to a printable format for the LCD screen.
So currently I’m lost, I’ve no idea were it could go wrong. But, that something goes wrong is shown by you.
Is someone working on this issue?
It’s annoying to carry around a tuner pedal in addition to a multi-effects pedal.
“just” converting values to a printable format can contain a lot of bugs. The values need to be re-calculated to fit the scale. The length of the thin and the thick bars need to be calculated. Maybe the cents value is taken from that (wrong) re-calc - just a few thoughts.
Oh, I’ve all that more than double checked.
What I would do now is moving the calculation for the cent value into the mod-controller instead doing that outside in the tuner.py script. That will ensure that the calculated offset is all-time in sync with the detected frequency, as it is calculated just in the moment were we show the frequency and cent on the screen. (I do it this way in all other tuners I’ve written so far and none of them has the issue we talk about here, hence I would like to eliminate the signal pipe)
I’ve it working on my dwarf already. Now I need to talk with @falkTX about it and he must have some time to review my changes.
Wow, that’s good to know. I always fail to reproduce your issue, but didn’t think about the Ref Pitch value. So it seems the Ref Pitch is initial set wrong on host side, but, because it never was changed the UI didn’t know that (no message). As, during development I surly changed the Ref Pitch, I didn’t noticed this issue. That, my friend, will be easy to solve. Thanks for this hint!
Still it may be a good idea to move the cent calculation into the mod-controller to get rid of the “man-in-the-middle” approve.
Yea, as we see in the screenshot above. The cent offset should be there 1.573 cent, not 0.3? cent.
Still it is much better because it match the designiert frequency centre, but it isn’t correct enough for serious usage ( like intonation).
I’ve worked out a solution now, but as I said, it will need a lot of corner case checks before it will be accepted by @falkTX. Don’t expect anything new before the next firmware release. Srry.