Link start/stop synchronization only follows explicit user actions and is not auto-applied when joining a session

As of Link version 3, peers can share transport start and stop commands across the session. Unlike tempo, beat, and phase — which are automatically synchronized when any peer joins — start/stop state is not imposed on a new peer at join time. Only explicit user-initiated actions (pressing play or stop) propagate to other peers. This design prevents newly joined apps from unexpectedly starting or stopping mid-performance. After joining, each peer begins listening for future start/stop changes. Because apps have different quantization behaviors, start and stop commands do not guarantee all apps will start at exactly the same sample — each app starts at its own next quantum boundary and phase.

Examples

Live is playing, a new VCV Rack Link module joins the session. VCV Rack does not automatically start playing — it waits until the user explicitly presses play, at which point it starts at the next quantum boundary. Contrast with tempo: VCV Rack immediately adopts Live’s current BPM on join.

Assessment

A new Link peer joins a running session. What parameters are immediately synchronized, and which require a user action to change? Why was start/stop designed to require explicit user intent rather than auto-sync?