MixScreen: load decks one at a time, stop blocking on both files - #42
Open
djdefi wants to merge 2 commits into
Open
MixScreen: load decks one at a time, stop blocking on both files#42djdefi wants to merge 2 commits into
djdefi wants to merge 2 commits into
Conversation
Previously MixScreen::start() required both f1 and f2 to be chosen before any audio would play, forcing users through the song list twice with nothing happening in between. Also, replacing a track via encBtnHold called stop(), destroying the whole MixSystem (and the other deck's playback) just to swap one file. Now: - start() constructs MixSystem and begins playback as soon as one file is available; the second deck can be loaded later while the first keeps playing (mirrors Denon Prime GO-style independent per-deck load). - returned()/loadChannel() route into the new MixSystem::openChannel() so loading/replacing a deck live no longer stops the other deck. - encBtnHold no longer calls stop(); it just closes the selected deck's file and reopens SongList, tracking which deck to fill via loadingChannel. Depends on the MixSystem::openChannel()/_openChannel() addition in JayD-Library. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> Copilot-Session: 1b2cfc57-c6c7-44ce-95c9-72368d409ca8
This was referenced Aug 22, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
MixScreen::start()required bothf1andf2to be chosen beforeany audio would play — you had to go through the song list twice with
nothing happening in between. Replacing a track also called
stop(),tearing down the whole
MixSystem(and the other deck's playback)just to swap one file.
Now:
start()constructsMixSystemand begins playback as soon as onefile is available; the second deck can be browsed/loaded later while
the first keeps playing (independent per-deck load/play, like most
standalone DJ controllers).
returned()/newloadChannel()route intoMixSystem::openChannel()so loading or replacing a deck live no longer stops the other deck.
encBtnHold()no longer callsstop(); it just closes the selecteddeck's file and reopens
SongList, tracking which deck to fill vialoadingChannel.Depends on
MixSystem::openChannel()/_openChannel()fromCircuitMess/JayD-Library#19.
Not covered here (flagged for follow-up, out of scope for this fix):
SourceAAC/SourceMP3::processReadJob()busy-waits on the audiothread when the async SD read hasn't completed yet, which can still
cause stutter independent of the loading UX fixed here.