Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Auto Dj + Sync enabled + Non const beat grid #9795

Closed
mixxxbot opened this issue Aug 23, 2022 · 15 comments
Closed

Auto Dj + Sync enabled + Non const beat grid #9795

mixxxbot opened this issue Aug 23, 2022 · 15 comments
Milestone

Comments

@mixxxbot
Copy link
Collaborator

Reported by: daschuer
Date: 2019-11-10T10:53:42Z
Status: Fix Released
Importance: Undecided
Launchpad Issue: lp1851985


With the new auto DJ into and outro modes, automatic beat matching is possible if you sync_enabled on both decks.

However this does not work well with non const beat grids because the playing track is nailed to the bpm of the stopped deck. This sound like a broken turn table.

I think we should update the sync feature, that it kicks in only if both decks are playing.

Any ideas how.

@mixxxbot
Copy link
Collaborator Author

Commented by: ywwg
Date: 2019-11-11T16:25:16Z


There are a lot of problems with master sync and non-const beatgrids. I have been doing a lot of hacking and thinking to try to figure out how to resolve some hard problems.

For instance: What should happen if a track with a non-constant grid slows down? I have a track that has a dramatic moment where it slows from 120 to 100bpm very quickly. Right now Mixxx keeps the BPM constant so this effect is lost (and the musical pitch suddenly rises unless I have keylock on). Should it be locked to the internal clock speed? Should it be allowed to slow down? What if there's another track playing? Should it slow down too?

In my exploration, it seems that mixxx needs a concept of which deck should be considered "in charge" for the purpose of master sync. We do have the idea of an explicit master deck, but in the current code this is an invisible Internal Clock -- that's why it appears that the non-const track is matching the stopped deck. In reality, it's matching the Internal Clock, which was initialized to some BPM (which may have been the first deck, but could have been the second deck if both were stopped).

Unfortunately trying to determine which deck "should" be master is very hard. What if the currently-playing deck is constant beatgrid, and a non-const beatmap track is loaded?

@mixxxbot
Copy link
Collaborator Author

Commented by: ywwg
Date: 2019-11-11T16:27:43Z


There are also a bunch of bugs with the current code:

  • quantize is broken if you try to start a beatmap track before the first beat, because the beatmap is not extrapolated beyond the beginning of the track, so mixxx can't do beat fraction calculation
  • The sync to internal master is a little broken (some off-by-one-buffer errors), so the pitch of a non-const track is nudged around unnecessarily
  • as stated above, syncing tracks with highly variable beatmaps is not great and produces a lot of warble.

@mixxxbot
Copy link
Collaborator Author

Commented by: Be-ing
Date: 2019-11-11T16:55:55Z


This doesn't really have anything to do with AutoDJ does it? Isn't this a duplicate of Bug #⁠1114643?

@mixxxbot
Copy link
Collaborator Author

Commented by: ywwg
Date: 2019-11-11T19:34:29Z


The fix as described would be a change to how master sync works. Changing how master sync works should be done very carefully because it's in a bad state. We shouldn't pile on auto-dj specific hacks, because that would paper over the underlying issue. If we can fix master sync, it will be fixed for auto-dj as a side effect.

@mixxxbot
Copy link
Collaborator Author

Commented by: daschuer
Date: 2019-11-11T22:12:54Z


This is a special case of Bug #⁠1114643

@mixxxbot
Copy link
Collaborator Author

Commented by: ywwg
Date: 2019-11-12T19:51:17Z


I think I know how to make a safe fix for this specific case:

If sync is on and only one deck is playing, that deck should be the master and stay at the same playback rate and the Internal Clock should follow it.

Or more generally: Internal clock should only be the master if more than one deck is playing. If one deck is playing, it is the sync master.

Once the second deck starts playing, the bpm will lock and they'll play in sync.

@mixxxbot
Copy link
Collaborator Author

Commented by: daschuer
Date: 2019-11-12T20:31:19Z


Yes this sounds reasonable and will work with auto DJ.

Does your idea match to this:
Sync enable on both decks.
Sync both decks wen engaging sync.
Let a single deck play freely on the adjusted rate. Let the paused deck follow, until playing. When both playing use a fixed bpm until the first deck stops.

@mixxxbot
Copy link
Collaborator Author

Commented by: ywwg
Date: 2019-11-12T20:42:51Z


I believe that should work, yes.

Master sync code is very hard but I should be able to work on this this weekend.

I have had a lot of problems using non-const tracks in my sets lately so I am motivated to fix this!

@mixxxbot
Copy link
Collaborator Author

Commented by: ywwg
Date: 2019-11-24T20:47:24Z


This is hard! But it is showing promise. I have a few more tests to fix / rewrite, and then I'll post a PR

@mixxxbot
Copy link
Collaborator Author

Commented by: ywwg
Date: 2019-11-24T21:09:19Z


One question I have: I need to iterate over the available syncables to find a bpm target, and I want to exclude Samplers. Is there way to only iterate over proper playback decks? (Right now there's a check for "!pOtherSyncable->getChannel()->isMasterEnabled()" but that only catches preview decks, not samplers).

@mixxxbot
Copy link
Collaborator Author

Commented by: daschuer
Date: 2019-11-24T21:34:26Z


You can call pOtherSyncable->getGroup() to check if it is a player.
Or add a flag set during the constructor to avoid repeated string compare.

@mixxxbot
Copy link
Collaborator Author

Commented by: Be-ing
Date: 2019-11-24T21:41:54Z


Launchpad is not a great medium to discuss implementation details because of the 15 minute delay before notifications are sent. Zulip would be better.

@mixxxbot
Copy link
Collaborator Author

Commented by: ywwg
Date: 2019-11-30T23:06:12Z


15 minute delay, lol, I am lucky to find time to work on this once a week. Anyway, still going, it's looking good. Been fixing lots of bugs too. I have to completely rewrite a couple tests, then I think it's ready for review.

@mixxxbot
Copy link
Collaborator Author

Commented by: ywwg
Date: 2019-12-02T02:02:48Z


#2376

@mixxxbot
Copy link
Collaborator Author

Issue closed with status Fix Released.

@mixxxbot mixxxbot transferred this issue from another repository Aug 24, 2022
@mixxxbot mixxxbot added this to the 2.3.0 milestone Aug 24, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant