Rockbox

Updated the patch:

- on large screens, the mode is displayed (Pitch Up/Down or Semitone Up/Down). On very small screens, there is no mode indicator. The right word is ‘semitone’, not ‘halftone’.
- in semitone mode, repeat is switched off
- pitch mode is retained between ‘pitch sessions’

TODO: semitone pitching is still not very accurate. Pitching up from 100% and then down will not result back in 100%. But for my purpose (comfortable strumming while listening to music) this is enough.

It’s now committable IMHO.

   pitch_semitone.patch (9.6 KiB)

PS. E.g. going one semitone up from 100.0% results in 105.9%. Then, going one semitone down results in 99.9% (and not 100.0%). This is due to the fact that pitch is held as an int.

Would it be possible to just use a hardcoded array of values for the percentage, rather than calculating each time and having to deal with round off errors?

Would it be possible to just use a hardcoded array of values for the percentage, rather than calculating each time and having to deal with round off errors?

No, I’m afraid no. Since you can change pitch in normal mode a bit, then switch to semitone mode, and then further fine adjust the pitch in normal mode.

Further updated the patch:

- solved the problem with inaccurate semitone pitch change. Now it’s really accurate.
- added key mapping for main device

TODO: key mapping for remote. I can’t and will not do that since I’ve never used the remote. Anyone?

Another note: on H120, reset to 100% on the main unit is mapped to PLAY. Why? Wouldn’t it be better to do it with NAVI? This would also allow to leave the pitch screen with PLAY.

   pitch_semitone2.patch (14.8 KiB)

Why not have a seperate pitch offset, then look that up from a table of 12 semitones and add it to the current pitch value? You could of course double/halve for octaves (if that much range is needed).

Committers? Anyone? Is the patch not good enough? I’m afraid if it doesn’t get committed fast something will become stale and will require much effort to keep up. (That probably happens to 90% of submitted patches.)

We’re not too happy about floating point operations in the core code. Use fixed point.

We’re not too happy about floating point operations in the core code.

Why not? Is it because not all devices (CPUs) support it? Because a performance issue it is definitely not.

None of our CPUs support it, so emulation code needs to be linked in, which makes both bigger and slower code than necessary. We use fixed point absolutely every other place where math like this is done, so we should do it here too.

None of the targets so far support floating point natively. I agree that it is hardly a performance issue in this case, however. I suspect that the binary size increases somewhat when you include floating point code.

Updated the patch: replaced floating point arithmetics with integers (well, actually long). I hope, unsigned long is at least 4 bytes long on all platforms.

Here are the pitches (as speed promille) when changing it in semitone steps (for quality assurance :

Up: 1059, 1122, 1189, 1260, 1335, 1414, 1498, 1587, 1681, 1781, 1887, 1999
Down: 944, 891, 841, 794, 749, 707, 667, 630, 595, 562, 530, 500

   pitch_semitone3.patch (15.5 KiB)

Sorry, forgot one thing: the constant should be used for initialising the pitch_mode

   pitch_semitone3_2.patch (15.5 KiB)

PS. The values above are computed when starting at 100.0%. If you change the pitch in normal mode and then switch to semitone mode, you’ll of course have other values.

One more small correction: use ‘uint32_t’ instead of ‘unsigned long.’

   pitch_semitone3_3.patch (15.5 KiB)