Auto Dj + Sync enabled + Non const beat grid

Bug #1851985 reported by Daniel Schürmann
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Mixxx
Fix Released
Undecided
Owen Williams

Bug Description

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.

Revision history for this message
Owen Williams (ywwg) wrote :

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?

Revision history for this message
Owen Williams (ywwg) wrote :

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.

Revision history for this message
Be (be.ing) wrote :

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

Revision history for this message
Owen Williams (ywwg) wrote :

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.

Revision history for this message
Daniel Schürmann (daschuer) wrote :

This is a special case of Bug #1114643

Revision history for this message
Owen Williams (ywwg) wrote :

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.

Revision history for this message
Daniel Schürmann (daschuer) wrote :

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.

Revision history for this message
Owen Williams (ywwg) wrote :

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!

Changed in mixxx:
assignee: nobody → Owen Williams (ywwg)
status: New → Confirmed
Revision history for this message
Owen Williams (ywwg) wrote :

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

Revision history for this message
Owen Williams (ywwg) wrote :

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).

Revision history for this message
Daniel Schürmann (daschuer) wrote :

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.

Revision history for this message
Be (be.ing) wrote :

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

Revision history for this message
Owen Williams (ywwg) wrote :

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.

Revision history for this message
Owen Williams (ywwg) wrote :
Be (be.ing)
Changed in mixxx:
status: Confirmed → Fix Committed
milestone: none → 2.3.0
Changed in mixxx:
status: Fix Committed → Fix Released
Revision history for this message
Swiftb0y (swiftb0y) wrote :

Mixxx now uses GitHub for bug tracking. This bug has been migrated to:
https://github.com/mixxxdj/mixxx/issues/9795

lock status: Metadata changes locked and limited to project staff
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.