How is the founding peer's timeline initialized?

[anweiss]

Trying to wrap my head around how the handleSuccessfulMeasurement function works when a new peer joins with a separate session. Let's assume that a controller is enabled, thus making it the founding peer ... let's call it SessionA. A new peer joins with a separate session called SessionB which is inserted into mOtherSessions. When handleSuccessfulMeasurement is called against SessionB, shouldn't SessionA be set as the current timeline since it is the founding peer?

[fgo-ableton]

Hey, handleSuccessfulMeasurement is actually doing what you expect it to do. In the case you are describing SessionA would be mCurrent. SessionB would be the incoming XForm. In L161 ghostDiff would likely even be negative, so mCurrent won't be replaced.

[anweiss]

Yep, this make sense, thanks @fgo-ableton. What I still don't understand is where the founding session's timeline's beat origin is updated. When a controller is enabled for the first time, resetState is called on L204

https://github.com/Ableton/link/blob/c4edbb2c74cdf44c12bb5495f949ab304944422a/include/ableton/link/Controller.hpp#L204

which then initiates a new beat origin based on the current host time on L541

https://github.com/Ableton/link/blob/c4edbb2c74cdf44c12bb5495f949ab304944422a/include/ableton/link/Controller.hpp#L541

But when broadcastState is subsequently called, where exactly does the founding session's timeline's beat origin get updated every time the peer's state is sent out via UDP multicast?

[fgo-ableton]

The timeline is not updated regularly when broadcasting. It is only updated when changing the tempo or adopting an incoming timeline.

[anweiss]

Thanks again @fgo-ableton!