Swiping up on metronome switches arc input to counter for higher precision

[borkymcgee]

Swipe up to switch the arc to a counter to make precise BPMs easier to input
Swipe down to switch back to the arc

Implements fix proposed in #1191 (comment)
Resolves #1191

[github-actions]

Build size and comparison to main:

Section	Size	Difference
text	377024B	224B
data	940B	0B
bss	63420B	0B

[minacode]

Two UIs seem like one too much for such a restricted device. I agree with the solution, though. Do you think the bpb setting could be made into a slimmer counter widget right of the tempo counter as well? With a long play/pause button underneath?

[borkymcgee]

Oops! Misclicked blush sorry!

[borkymcgee]

@minacode I think you can have arbitrarily sized counter elements, so you COULD probably do that.

I'm not sure it's a good idea though:

-I think it'd look garish
-That's a lot of little touch buttons for one small screen
-I'm not sure there are any problems with the dropdown as-is, it seems a good UI fit for the application

[minacode]

Ok, fair points. I almost never use the metronome, so maybe I should not argue too much about its usability.

1. This is the only drop-down in the whole code base, right? Could we make the UI more consistent and remove some lvgl code if we replace it? The diff of the resulting image would be interesting.
2. The argument regarding too much stuff is not that valid, because the time settings or the alarm have the same UI with two counters.

[borkymcgee]

I don't use the metronome function either, so it's hard to know what usability is like

I was imagining the bpb counter being smaller than the bpm one, since it's less important. I like the way the current design puts the bpm front and center and big, with bpb and start/stop smaller. It gives the app a simple, clean feel.

If we can figure out a good alternative, removing the dropdown might be a good idea, especially since it's a bit buggy (#1806).

[Baggypants]

I want to use the metronome but it's current input is utterly hopeless, so I don't. Tapping the requested bpm in binary coded decimal using morse code would be better ux than what you have currently in 1.14.0

Having an 'up' only button that increments every value between 0 and 600 and loops round to zero would be more accurate, and faster.

[Baggypants]

What about using the input method for the stop watch, move to colon to be between the 3rd and 4th element so the first three would set hundreds, tens and units and the 4th one would be 0-9 for beat. Sure anyone who has a piece in 11/4 or 17/4 might complain but I'd suggest they already have bigger problems.

[vkareh]

Honestly I think using an arc is the wrong widget for precise input. It works for something like the shake calibration because it's a gradual sensitivity thing. It works for steps because it's a visual read-only widget.

It does not work to select precise bpm values. In my opinion it should be an up/down input only, then you can create side-by-side bpm and bpb widgets and solve both issues in one shot.

[mark9064]

The one thing I like about the arc is that keying in the BPM approximately is pretty fast - ideally you want to be able to quickly select any frequency (roughly) in the range and then refine it.

I'm not totally sure what'd work better though. Does tap tempo still work with this branch? I think tapping to set it approximately and then refining with the spinner would be OK

[NeroBurner]

just got bit by the not precise enough input to the metronome. I don't know if this PR is the best way to solve the issue, but it is much better than just the arc.

Adding it to Milestone 1.16.0 to get some eyes on the PR

@borkymcgee would you be interested to rebase the PR on the current main branch?

[minacode]

To give this some direction: if you will build the app only with the second screen with the +-number input, tapping on the number as alternative input and the bpm as a simple button that cycles through numbers (2-8?; like the "once"/"mon-fri"/"daily" button for the alarm), I will approve it.