I think this logic belongs in getSyncAdjust(). 

and I want to check with you on a subtlety of how the data flows.

1) Callback starts, master deck is process()'d or master clock is incremented. If master deck is selected, the beat distance from BEFORE this callback is complete is used (see BpmControl::process()). You left a comment saying this gets better sync. If master clock is selected, the master clock beat distance AFTER this callback is used.

2) The master beat distance change triggers this slot.

3) This method uses the current deck's position BEFORE this callback is finished (since process() has not run on this deck yet) to calculate its beat ratio compared to the master beat distance BEFORE the callback is finished in the case of master deck and AFTER the callback is finished in the case of master clock.

4) If user was tweaking sync on this deck in the PREVIOUS callback, set the user-offset and set m_dSyncAdjust to 1.0. Otherwise set m_dSyncAdjust to proportional control applied to the error of this beat distance with the master beat distance.

5) RateControl::calculateRate runs, getSyncAdjustment() is called and the sync adjustment is multiplied with the rate. 

Questions based on this:

* Why the discrepancy between master clock and master deck in which beat distance is used?
* Is using the PREVIOUS callback tweaking-sync intentional? Why not the current callback tweaking-sync?

Maybe the reason BpmControl::process() uses the previous callback's ending position is because before that was added you found that the sync adjustment calculated by comparing a BEFORE position to an AFTER position produced higher errors (which in turn makes P-control harder and more likely to produce oscillations / instability). Could you explain what the context was when you made that change?