Request: ability to select time windows within SortingAnalyzers

[lfrank]

We are working on linking units across sortings, and as there is always some unit instability over time, we've found that this requires comparing the waveform properties from the end of one recording with those from the beginning of the next recording, particularly for continuous recordings where we're sorting a day at a time.

We'd therefore like to be able to specify template extraction and potentially other metrics limited to specific windows within a sorting as a SortingAnalyzer feature so that users can do the matching across datasets.

I think this could be broadly helpful and will be a more and more important feature as people move toward longer recordings.

[zm711]

I absolutely agree with this and keep meaning to bring this up at maintenance meetings. We've been meaning to extend the random_spikes to allow for finer control (ie get waveforms from specific time periods) for a while but no one has taken it on. I need this too for my work as I would really love to easily demonstrate that the waveforms aren't changing during stimuli as a control metric (especially during opto which is many people do these days). Once we have a random_spikes that is fine-tuneable I could imagine either a slicing mechanism which seems complicated or just a recommendation to make 5 analyzers subsetting your data and running the same pipeline on the self cut-up data.

Is one of those options what you'd want too?

[lfrank]

In a perfect world I’d want a very flexible slicer where we could specify the time intervals or spike indexes, perhaps in something like a numpy indexing format so you could do [-1000:0] to specify the last 1000 elements. If that’s too difficult to implement, at minimum we’d need to be able to specify the time windows, as depending on the level of instability and the length of the recording, we might want the last 500 or 5000 spikes, or perhaps the last 10-30 minutes of spiking in a 24 hour period. On Sep 9, 2025, at 5:07 AM, Zach McKenzie ***@***.***> wrote: This Message Is From an External Sender This message came from outside your organization. [https://avatars.githubusercontent.com/u/92116279?s=20&v=4]zm711 left a comment (SpikeInterface/spikeinterface#4133)<https://urldefense.com/v3/__https://github.com/SpikeInterface/spikeinterface/issues/4133*issuecomment-3270403985__;Iw!!LQC6Cpwp!oSKcTcgW4Q6J0_ooyNEWf8-2tKHQSAk4ADnPKqn6XsbbGqWObUmRwUd66tHFqUhbpF4iAOLn9n6eb4y_3U82WjqN6Q4$> I absolutely agree with this and keep meaning to bring this up at maintenance meetings. We've been meaning to extend the random_spikes to allow for finer control (ie get waveforms from specific time periods) for a while but no one has taken it on. I need this too for my work as I would really love to easily demonstrate that the waveforms aren't changing during stimuli as a control metric (especially during opto which is many people do these days). Once we have a random_spikes that is fine-tuneable I could imagine either a slicing mechanism which seems complicated or just a recommendation to make 5 analyzers subsetting your data and running the same pipeline on the self cut-up data. Is one of those options what you'd want to? — Reply to this email directly, view it on GitHub<https://urldefense.com/v3/__https://github.com/SpikeInterface/spikeinterface/issues/4133*issuecomment-3270403985__;Iw!!LQC6Cpwp!oSKcTcgW4Q6J0_ooyNEWf8-2tKHQSAk4ADnPKqn6XsbbGqWObUmRwUd66tHFqUhbpF4iAOLn9n6eb4y_3U82WjqN6Q4$>, or unsubscribe<https://urldefense.com/v3/__https://github.com/notifications/unsubscribe-auth/ABV4PSLSCVBSFXLORYGOD5T3R27IPAVCNFSM6AAAAACGAPISFKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTENZQGQYDGOJYGU__;!!LQC6Cpwp!oSKcTcgW4Q6J0_ooyNEWf8-2tKHQSAk4ADnPKqn6XsbbGqWObUmRwUd66tHFqUhbpF4iAOLn9n6eb4y_3U82sCuFkWI$>. You are receiving this because you authored the thread.

[chrishalcrow]

Hello, started a draft PR #4147 - mostly to see what the technical problems might be: feedback welcome!
The hard work is implementing a splitting method for every extension.

[zm711]

So we discussed this a bit yesterday and are thinking of a soft vs hard divide (although @chrishalcrow add more comments because I'll be brief here). For a soft analyzer time slice we would allow for a mechanism like Chris is proposing in #4147. A hard split would have the official recommendation of doing time/frame slices on the recording object and the sorting object and making a series of sub analyzers which can then all be analyzed in the same way.

The major disadvantage of the soft analyzer split/slice mechanism is that if the user has provided two small default spikes in random_spikes, then the time division made lead to an analyzer slice with no spikes in it. This doesn't affect all things (spike vector is okay like amplitudes), but things like templates may not be recomputable (because you don't have enough waveforms left if you have waveforms or you don't have waveforms and so we would need the recording anyway). So this leads to a divide in what can reasonably sliced. We are still thinking about this broadly, but if you want the safest option from a data perspective (where all extensions are guaranteed to work with an appropriately sized slice) the better option is to this at the create_sorting_analyzer level!