Metronome face tap tempo

[redraw]

This PR adds tap tempo feature to the metronome face by using the light button and/or accelerometer taps.

When light button is pressed, tap tempo logic starts measuring taps from light button and accelerometer tap event, if available. Similar to the countdown face, the signal indicator is turned on. After TAP_DETECTION_SECONDS is exceeded, the tap tempo detection is disabled, accelerometer tap detection is aborted, and the signal indicator turned off.

I worked inside legacy folder to be able to see the git diff, while adding symbolic links inside watch-faces folder to test.

I've found that the emulator is not responding to all button presses at 64hz rate, some are skipped. That's not happening in hardware.

[redraw]

Some work is also required to make the existing metronome timing more precise. I've recorded some metronome plays, run a BPM tempo detector script using librosa, and found out it's mostly accurate at low tempos, but drifts at higher ones

[redraw]

This is metronome set up at 150 bpm. BPM detected at 143.6

150bpm.mp4

[redraw]

Still needs refactoring using the new watch_display_text() method

[Austoria]

Hey, I wrote the initial metronome face, was planning on doing a tap tempo soon but you beat me to it!

The metronome has always been a bit off and I also found that it drifts based on the tempo. My best guess was that there was some delay added by either updating the screen or triggering the beep that caused the state->curTick counter to fall behind.

There will always be some inaccuracy because the bpm subdivisions won't always fall on one of the 64hz ticks but I tried to correct for that and still saw this same drift.

I'll try to mess around with this and see if I can't find the leak.

[redraw]

Hi nice watch face! that's one of the first things I wanted to code in a sensor watch and found it. Feel free to hijack on this one. I guess tap tempo is working ok, maybe 8 is too many measurements to average, 4 would be quicker

[Procsiab]

Hello there, since a little bit has passed fron the latest activity on this topic, I would like to point about an interesting finding of the user @alesgenova regarding a bug that made each beep of the buzzer a little bit longer than it should: maybe is this that contributes to metronome drifting?

Relevant commit in his branch:
d3968ae

Also, in the meantime another user has an opened PR to add tap support in the emulator, which could help in testing the developement of tap tempo detection:
#94

[alesgenova]

@Procsiab
Yes, I checked the code and metronome could be affected by the bug I discovered.

But I think there are other reasons for the drift as well. I see that we request 64Hz ticks and then play a short sequence, finish, start a new short sequence and so on.
Each time a new sequence starts, a new timer is created. I can see things drifting once we get to higher tempos.

In my branch I have implemented an alternative way to play a sequence, where you just pass a source function that could play indefinitely, only starting the sequence timer once. Could be worth seeing if these two things together solve the drift.
Relevant commit here: bce7ea1

[redraw]

Hi, I've already tested alessandro's fix here. I'm actually soundblaster in the forum. I also hoped this issue got indirectly fixed by that but tested beeps at 120bpm and unfortunately bpm detector still results in 117bpm. I'll dive into the existing code soon and come back!