Skip to content

Define how an in-place stream/start treats buffered visualizer data - #307

Open
kahrendt wants to merge 1 commit into
mainfrom
fix/visualizer-in-place-stream-start
Open

kahrendt wants to merge 1 commit into
mainfrom
fix/visualizer-in-place-stream-start

Conversation

@kahrendt

@kahrendt kahrendt commented Oct 11, 2026 •

Copy link
Copy Markdown
Contributor

The visualizer role didn't define how an in-place stream/start treats data received under the previous configuration, which messaging.md leaves to each role. Match the player: frames sent before the update keep the previous configuration, and clients keep buffered frames and interpret each under the configuration in effect when it was received. Also state that an in-place stream/start doesn't reset the buffer_capacity count, as the player role does.

This matches what the existing timestamp-ordering (#229) and buffer-accounting (#232) rules already assume, and what sendspin-server and the aiosendspin server do.

Closes #306

Breaking changes

  • sendspin-cpp: drops all buffered visualizer frames on any stream/start and decodes at delivery time with the current n_disp_bins. It must keep frames across an in-place start and decode each under its own configuration.

  • I accept the Contributor License Agreement for this contribution.

Keep buffered frames and interpret each under the configuration in effect when it was received, matching the player role. An in-place `stream/start` does not reset the `buffer_capacity` count.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Define how an in-place stream/start treats buffered visualizer data

1 participant