What problem does this solve?
stemdeck-speed-slider-and-dropout-fix.patch
The playback control never worked like I wanted. Also when playing slower, then playback begins to stutter. So I thought lets try vibe coding. To my surprise the result is impressive. No stuttering anymore and a smooth slider for speeds between 80% and 100%.
Since I can not create a pull request, I`m sharing a patch file against origin/main (ba97092) .
git checkout main && git pull
git checkout -b speed-slider-and-dropout-fix
git apply /path/to/stemdeck-speed-slider-and-dropout-fix.patch
git commit -am "fix(ui): practice-speed slider; fix(engine): dropout-free slowed playback"
git push -u origin speed-slider-and-dropout-fix # then open the PR from that branch
Description:
fix(player): practice-speed slider (0.8x-1.0x) and dropout-free slow playback
The Speed control was a two-position 0.75x/1x switch; some fills only
need a small nudge, so it is now a continuous 0.8x-1.0x dial in 0.01
steps (desktop footer and mobile player share the same range and step).
0.8x stays the floor because below that time-stretch artefacts dominate
(#433), and the snap-to-step keeps the readout and the applied rate from
ever disagreeing.
Backing the dial up with anything below 1x exposed a scheduling bug in
the chunked engine. _scheduledTo is measured in source seconds, which
advance at 1.0x, but the lookahead gate compared it against
getCurrentTime(), the output playhead scaled by _playbackRate. At
rate < 1 that playhead shrinks faster than the wall clock, so the engine
read itself as further ahead than it really was, waited too long to
schedule, and let the pre-scheduled margin drain at (1 - rate) seconds
per second until the chunk sources ran dry: audible gaps that arrived
sooner the slower the speed (~2 min at 0.8x, ~3 min at 0.9x).
The gate now uses an input-rate clock (_scheduledPlayhead), the media-
time inverse of the scheduling _scheduleNext already performs, so at
any rate the engine keeps chunk sources at least LOOKAHEAD_SEC ahead.
Rate 1x behaviour is unchanged.
Mobile: the speed dial matches the desktop range and step.
Tests: transpose.spec.mjs drives the slider instead of the removed
buttons.
Proposed solution
Check if provided patch can be accepted.
Alternatives considered
No response
What problem does this solve?
stemdeck-speed-slider-and-dropout-fix.patch
The playback control never worked like I wanted. Also when playing slower, then playback begins to stutter. So I thought lets try vibe coding. To my surprise the result is impressive. No stuttering anymore and a smooth slider for speeds between 80% and 100%.
Since I can not create a pull request, I`m sharing a patch file against origin/main (ba97092) .
git checkout main && git pull
git checkout -b speed-slider-and-dropout-fix
git apply /path/to/stemdeck-speed-slider-and-dropout-fix.patch
git commit -am "fix(ui): practice-speed slider; fix(engine): dropout-free slowed playback"
git push -u origin speed-slider-and-dropout-fix # then open the PR from that branch
Description:
fix(player): practice-speed slider (0.8x-1.0x) and dropout-free slow playback
The Speed control was a two-position 0.75x/1x switch; some fills only
need a small nudge, so it is now a continuous 0.8x-1.0x dial in 0.01
steps (desktop footer and mobile player share the same range and step).
0.8x stays the floor because below that time-stretch artefacts dominate
(#433), and the snap-to-step keeps the readout and the applied rate from
ever disagreeing.
Backing the dial up with anything below 1x exposed a scheduling bug in
the chunked engine. _scheduledTo is measured in source seconds, which
advance at 1.0x, but the lookahead gate compared it against
getCurrentTime(), the output playhead scaled by _playbackRate. At
rate < 1 that playhead shrinks faster than the wall clock, so the engine
read itself as further ahead than it really was, waited too long to
schedule, and let the pre-scheduled margin drain at (1 - rate) seconds
per second until the chunk sources ran dry: audible gaps that arrived
sooner the slower the speed (~2 min at 0.8x, ~3 min at 0.9x).
The gate now uses an input-rate clock (_scheduledPlayhead), the media-
time inverse of the scheduling _scheduleNext already performs, so at
any rate the engine keeps chunk sources at least LOOKAHEAD_SEC ahead.
Rate 1x behaviour is unchanged.
Mobile: the speed dial matches the desktop range and step.
Tests: transpose.spec.mjs drives the slider instead of the removed
buttons.
Proposed solution
Check if provided patch can be accepted.
Alternatives considered
No response