thebigg73
commented
1 year ago Unfortunately Android has poor timing - fact. Android receiving the request and playing the note on a busy system is the issue. Particularly if we used background threads - the system prioritises for us.
V5 tried to manually measure and recalculate the sending of the next note based on the length of the sound starting from when the note should have been sent by making the silence at the end of a note longer or shorter. Both v5 and v6 glitch and the simplest thing would be to remove the metronome. I'll have a look at moving some code in V6 to the foreground at the risk of blocking the UI. On my slow old device V5 metronome was totally unusable and logged 120bpm songs sending beat requests anywhere between 100 and 125 BPM. Almost always ending up behind where it should have been. V6 sends 120bpm requests each time (see previous discussion thread with logcat). This means overall the beats are always synced to the clock and will fix on system resource clearing. We don't try to ignore the best/most stable timer source we have available on the device. V6 always catches up and beat requests are always locked to the system clock, fact, but I accept that system delays, background threads, etc mean the sound (or visual flash) is sometimes on catch-up. Most common during song indexing completion for me.
V5 uses a manual listener to monitor and adjust sending of notes around a manual timer measured relatively to the system timer by creating different length silences after a beat, not sending the next note until after IT THINKS the note has been played. This builds in different beat lengths still assuming the request and playing are the same thing. When a beat glitches, the delay or reduction of delay is added in (on top of previous delays or shortening) and the next beat is measured from this new time point and calculations continue from there. This ignores the system clock thinking it is doing better by trying to fix each beat, but over a short period of time, this causes external devices to drift out of sync.
I'd often play with a keyboard player triggering a midi start on his device and metronome on my device (for the start of a song). On v5 by 30s in to the song the two devices were often out by nearly half a bar despite having the same tempo set (very occasionally they were close enough). We monitored the tempo flashes gradually drifting apart. V5 always getting slower when another task happened (e.g a notification popping up). I ended up abandoning the metronome on that device (an older, slower Android tablet). Moving to V6, the two devices are locked perfectly, and yes, I occasionally hear a faster beat or slower beat as my system catches up, but the system timers are locked in and I know that 30s in on my system clock also means 30s in on his system clock.
Returning to v5 timing methods would be a huge downgrade for me.
I suppose it comes down to a definition of stability. 120bpm = 120bpm with glitches when there is system load, but still 120bpm staying at 120bm overall, or ignoring actual system timing to mask glitches and 120bpm being dependent on processor speed and system load and having relative timing.
On Sat, 27 May 2023, 07:50 iv-gha, @.***> wrote:
Facts: Fast beat metronome is unstable. Metronome use with Pad makes this more pronounced (6/8 80 bpm with Pad being a case). Metronome pause/resume behaviour is poor. I think, a metronome stop calls need to be made on pause.
Visual/sound metronome needs stability for all speeds and when the sounds system is under stress.
v6 uses different technologies for Metronome sound. v5 metronome code uses, I believe, a self adjusting lock with the clock for start of sounds - this, with caveat that first few beats could drift, may be a way to get v6 stable.
— Reply to this email directly, view it on GitHub https://github.com/thebigg73/OpenSongTablet/issues/239, or unsubscribe https://github.com/notifications/unsubscribe-auth/AB3X52R3CYRFOYU7Z25BLILXIGPZTANCNFSM6AAAAAAYQ76E2M . You are receiving this because you are subscribed to this thread.Message ID: @.***>
iv-gha
Data: Fast beat metronome is unstable. Metronome use with Pad makes this more pronounced (6/8 80 bpm with Pad being a case). Metronome pause/resume behaviour is poor. I think, a metronome stop calls need to be made on pause.
Visual/sound metronome needs stability for all speeds and when the sound system is under stress.
v6 uses different technologies for Metronome sound. v5 metronome code uses, I believe, a self adjusting lock with the clock for start of sounds - this, with caveat that first few beats could drift, may be a way to get v6 stable.