THALis: window-buffer contract and sample-rate inconsistency

wait 94 samples at 250 Hz is 376 ms, not 750. need to find where the effective rate changes before using any of these latency numbers

Objects: RealTimeWindowBuffer, WindowConfig, LabeledWindow, and an on_window callback in src/unicorneeg/pipe.py (0232d5b). Alpha/beta outputs are stacked into 16 derived channels from eight electrodes.

Important inconsistency in the archive: it calls 94 samples “750 ms at 250 Hz” and 16 samples “125 ms.” At 250 Hz those counts correspond to 376 ms and 64 ms. The documented durations are closer to what those counts would imply near 125 Hz. A downsampling stage may explain the discrepancy, but the log alone does not establish one.

Before reusing settings: inspect the effective sample rate entering the buffer, sample-count rounding, window/stride configuration and output timestamps. Keep configured milliseconds distinct from realized sample counts.

Questions: does a window timestamp mark its start, end or center? How are partial windows, gaps and rejected artifacts handled? Classification cadence and latency must be calculated from the actual buffer configuration, not repeated from the inconsistent narrative.

Archived code references: 0232d5b.

MNE real-time decoding example