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.
4 Likes
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.
4 Likes
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
1 Like
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.
4 Likes
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.
5 Likes
For future checks please tell me the correct frequencies for B0, E1, A1, D2, G2, C3. Thank you.
1 Like
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
7 Likes
yes, because the errors i observed weren’t an offset… they are equally wrong, both negative and positive.
1 Like
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.
4 Likes
For me as a bass player the cent number is completely irrelevant. As long as there is a correct +/- bar visible I don’t care about 1.5 or 0.3 or 27.345678 
That is true as long you are not going to do intonation 
2 Likes
thanks to @brummer testing and attempts at fixing this we might have found an issue.
a string conversion (for message passing) is not being done in the correct way, so the cents value as received by the controller side can end up being wrong.
issue has been there since the Duo days (so basically since the start) but was not very noticeable there as used to use a lower precision for the “cents” value.
here is a Dwarf OS image/build with this data type fix https://pipeline.mod.audio/image/655521f2702cac5387451ce1/file
8 Likes
thanks, @falkTX … that works well, except the C number is wrong by a factor of 100. i.e. the decimal point should move two digits to the right.
a frequency which is 10 cents sharp reads as +0.10 C
a frequency which is 20 cents flat reads -0.20 C
etc…
…or are you regarding this as a decimal semitone value? if so, it shouldn’t be labeled as Cents, right? as it stands, it’s confusing…
3 Likes
you are right, the cents as shown on screen should be -49 to 49 range.
here is a new build with a proposed fix https://pipeline.moddevices.com/image/655b807b8a93ccfa8d5bb3b3/file
let me know what you think, thanks
1 Like
hi @falkTX – thanks for all your work on this - i’m glad this thing is getting sorted out! i don’t use the tuner, but it seems like a good thing to get right for other folks!
the numbers all look correct now.
however, i’m wondering about the functionality of the graph at the bottom. as it stands, here’s what’s happening:
-9 to +9 : indicator at the centre position.
+10 to +19 : indicator at 1/2 tick-mark. (mirror for -)
+20 to +29 : indicator at 1 tick-mark (mirror for -)
+30 to +39 : indicator at 1-1/2 tick-marks (mirror for -)
+40 to +49 : indicator at 2 tick-marks (mirror for -)
questions about all that:
- why are we only using 2/5 of the available graph space?
- why do we have such big jumps, when there’s clearly room for intermediate graph readings? (as it stands, the graph has only a 10C resolution - and only 20C around 0)
- why is the graph indicator just a moving 1-pixel line? (it would be much more readable as a solid bar, expanding in the + or - direction)
thoughts?
1 Like
hey @falkTX … i think the changes you’ve made to the tuner display in Release 1.13.4 are really great. …a really good balance between detailed information and “it’s close enough or it’s not”!
for my money, i’d just suggest one very small tweak:
the moving bottom half of the bar graph (when we’re beyond ±10C) currently is only 2 pixels wide… there’s one more available pixel – 3 pixels would just make it more clear from a distance.
…my $0.02… thanks for all your work!!
1 Like
@plutek The bar graph has the following specs:
Top bar resolution 0.1 cent (0.2 cent per tick mark, total 1 cent), height 1 pixel
middle bar resolution 1 cent ( 2 cent per tick mark, total 10 cent) height 3 pixel
bottom bar resolution 10 cent ( 10 cent per tick mark, total 49,9 cent), height 2 pixel.
2 Likes