tape position display may drift after looping

[catfact]

https://github.com/monome/norns/blob/main/lua/core/menu/tape.lua#L122-L123

we do not try very hard to make it not drift; we are just assuming that the actual seconds spent playinfg the file is equal to the elapsed seconds recorded by the system clock. (this is never really true.)

improvement would involve explicit periodic sync with the audio thread.

at the moment it doesnt seem worth it to build that and i would rather just hide the display widget.

in v3 it will be relatively trivial to add a direct getter for the current tape position.

---

also, it seems to me that the drift would be more noticeable with a slow sdcard, needing longer to prime the streaming buffer in between loops. indeed nobody has reported an issue with this until recentlty (while using a UHS-1 card and also experiencing audible dropouts in playback.)

[tehn]

this issue i believe got more pronounced with looping

https://github.com/monome/norns/blob/main/lua/core/menu/tape.lua#L122

fwiw, particularly in non-looped mode on a long sample, it's nice to visually spot when it's approaching the end. particularly if it's an accompaniment. i agree that in looping mode it's less meaningful, and definitely a problem if it's just really wrong

[catfact]

yes indeed. its wrong enough.

whatever, its not a huge deal to add a position callback, its just one more OSC channel and data stream from audio thread. my question is whether to do that now or just not biother until v3 (on which it becomes insignificant both in terms of code and runtime cost.)

[dndrks]

small report bump cuz it was part of testing a unit today on both standard norns and two different shield units, but i'm seeing the TAPE seconds counter (not just lil progress widget) being ~four seconds off on the first pass of hermit-leaves, before it even loops back around.

[catfact]

if this is considered urgent enough to keep looking at it and to keep bumping the issue, i should just create a fix. its not difficult. the current version of the feature is very much a hail mary that does not even involve real position updates from the audio thread. (it has always been pretty wrong.)

[tehn]

my vote is v3

…

On Wed, Mar 16, 2022 at 4:44 PM ezra buchla ***@***.***> wrote: yes indeed. its wrong enough. whatever, its not a huge deal to add a position callback, its just one more OSC channel and data stream from audio thread. my question is whether to do that now or just not biother until v3 (on which it becomes insignificant both in terms of code and runtime cost.) — Reply to this email directly, view it on GitHub <#1528 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAB4I4AVXUOBUSL32X2VOZDVAJB2RANCNFSM5Q2PSK7Q> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you commented.Message ID: ***@***.***>