I am working on ndx-spikesorting with @alejoe91, where I am mapping the concept of intervals in SpikeInterface to NWB. I want to ask three design questions about the scope of valid_unit_periods and the periods argument in the metric extensions:
-
On the role of valid_unit_periods's output: is its per-unit interval output valuable as standalone data (for visualization via ValidUnitPeriodsWidget, curation decisions, downstream user analyses outside SpikeInterface), or is its only purpose to produce intervals that restrict the computation of metric extensions?
-
On interval calculation: should valid_unit_periods remain the only extension that calculates per-unit intervals, or should multiple extensions for different algorithms (Bombcell-style criteria, drift-aware variants, faithful npyx ports, etc.) coexist as siblings?
-
On the periods= argument: should quality_metrics (and spiketrain_metrics) accept only intervals from quality-driven sources like valid_unit_periods, or also arbitrary intervals (behavioral epochs, trial structure, drift-corrected windows, etc.)? What was the intent here?
From reading the code, my current interpretation is:
valid_unit_periods is the canonical (and only expected) source of per-unit time intervals; the meaning of these intervals is generically "times where the sorting is good."
- The metric extensions'
periods= argument is meant to consume intervals only of that type: "times where the sorting is good."
Having these clarified would help me map the SpikeInterface structures to NWB cleanly.
I am working on
ndx-spikesortingwith @alejoe91, where I am mapping the concept of intervals in SpikeInterface to NWB. I want to ask three design questions about the scope ofvalid_unit_periodsand theperiodsargument in the metric extensions:On the role of
valid_unit_periods's output: is its per-unit interval output valuable as standalone data (for visualization viaValidUnitPeriodsWidget, curation decisions, downstream user analyses outside SpikeInterface), or is its only purpose to produce intervals that restrict the computation of metric extensions?On interval calculation: should
valid_unit_periodsremain the only extension that calculates per-unit intervals, or should multiple extensions for different algorithms (Bombcell-style criteria, drift-aware variants, faithful npyx ports, etc.) coexist as siblings?On the
periods=argument: shouldquality_metrics(andspiketrain_metrics) accept only intervals from quality-driven sources likevalid_unit_periods, or also arbitrary intervals (behavioral epochs, trial structure, drift-corrected windows, etc.)? What was the intent here?From reading the code, my current interpretation is:
valid_unit_periodsis the canonical (and only expected) source of per-unit time intervals; the meaning of these intervals is generically "times where the sorting is good."periods=argument is meant to consume intervals only of that type: "times where the sorting is good."Having these clarified would help me map the SpikeInterface structures to NWB cleanly.