Comment 1 for bug 1449747

Please give an example how to reproduce the issue.

Not sure if I got the point exactly right, but here some comments and questions:
* Sync phase on every loop
   -> what does it mean?
* More-aggressive error-control when loops are enabled. (con: could oscillate pretty badly)
  -> that sounds not a good idea
* Calibrate the out point of the loop so it's in sync even if the out point is not on the beat.
 -> this sounds reasonable
* Calculate a constant bpm that will keep the loop exactly in sync on the in and out, but only mostly in sync the rest of the time.
 -> sounds hard

Lets step back and view at both tracks as a constant streams.

Beatlooped track, is a stream with a const bpm, right? At least the distance from loop end and start is const.

If the looped track is the master, then it should be correct to use the average beats/ loop length, for short loops.

If the the other track is the master, with a non const beats, you hit a pending issue here here that the a non const beat master does not work very well without loops as well.

I have not tested it intensive with the latest master, but from my last test, the syncing was too aggressive. I think the algorithm must not sync against the beats in the beatgrid but to a "sync grid" that takes different condition into account
1. conts shifts over the track, (because the drummer gets tired)
2. breaks and short phases with differnt beats
3. Garbage at the track start/end (I lately suffered this issue)

IMHO using a non const track as sync master is a rare use-case. The real issue is that you like to have a synced transition from a non const beat track to an other. Both tracks may start/end with a beatloop (The issue from this bug). This should work like a charm.

We should optimize mainly for that that issue. hopfully the other use-cases will benefit from it.