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 1.13.3.3256 - should be up-to-date
Are your Dwarf up to date ?
Did you set another reference frequency than 440Hz ?
The MOD browser page says “up to date”
Where can I set the reference frequency?
Do you use a Dwarf a Duo or a Duox ?
There was a issue reported already for DuoX here:
which resulted in a quick DuoX Bug Fix test build here:
Correct. That should be 1.26 cent not 3.34 cent. I’ll investigate.
Still, when you get closer to the 55Hz the result should become better. Or when you match 55Hz is the offset still there?
On a bass you will never get an exact match. The low frequency and the reflections from all sides always result in some deviation over the time of measurement.
What I can see: if the freqeuncy goes over 55 Hz there is still a -2.x cents on the screen.
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:
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.
There must be someone with a debugger out there…?
I don’t know if it can be helpful, but did you try to change the A4 reference to match desired tuning? This workaround probably will works until the problem be solved
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.
Crazy things are going on here - today the tuner seems to work!
The only thing that I did: I turned the knob to change the reference up and down and back to 440.
For future checks please tell me the correct frequencies for B0, E1, A1, D2, G2, C3. Thank you.
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.
As in any frequency table you could find. first one here is:
https://pages.mtu.edu/~suits/notefreqs.html
yes, because the errors i observed weren’t an offset… they are equally wrong, both negative and positive.
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.
