Link session state must be captured before reading and committed after writing to ensure consistency

Link’s API provides session state as a snapshot that must be explicitly captured before use and committed back to Link after any modifications. Reading Link timing data without capturing first can produce inconsistent results within a single computation because other network participants may update the session state asynchronously mid-calculation. The capture-commit model guarantees that a captured state remains consistent for the full duration of one computation. Once modifications are made to a captured state (e.g., setting a new tempo), they are not active until the state is committed back to Link. This design is particularly important in audio callbacks where timing must be sample-accurate.

Examples

Correct audio thread pattern: (1) capture session state at start of audio callback, (2) read beat time and tempo from it, (3) render audio, (4) if tempo changed, modify the captured state, (5) commit it back. Never query Link directly mid-buffer — always use the captured snapshot.

Assessment

Explain why querying Link’s beat time directly without capturing session state can produce inconsistent results. What would go wrong if you committed a session state modification from the main UI thread while also modifying it from the audio thread?