-
Notifications
You must be signed in to change notification settings - Fork 221
Add multi-segment capability to BaseRasterWidget and children #3805
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
Hey @chrishalcrow - sorry for the delay working on this, I've been away for a while. Think I've addressed your comments, let me know if there's anything else you think could be improved here! |
st = sorting.get_unit_spike_train(unit_id, segment_index=seg_idx, return_times=True) | ||
if len(st) > 0: | ||
max_time = max(max_time, np.max(st)) | ||
duration = max_time |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's a bit simpler to do this using the full spike train all at once. You get this using
spikes = sorting.to_spike_vector()
then spikes has a segment_index
which can be used to figure out the segment lengths:
segment_slices = [np.searchsorted(spikes["segment_index"], [segment_index, segment_index + 1]) for segment_index in segment_indices]
segment_lengths = [segment_slice[1] - segment_slice[0] for segment_slice in segment_slices
then you gotta convert to time using sorting.sampling_frequency
.
Although it's a bit convoluted, I think using this would simplify the code a bit, and I'd be tempted to use it instead of the recording, because then we remove any mention of recording
s in this function.
(This is a bit messy because we don't keep track of the segment length in the sorting object )
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've made the change, but do you not think that removing the option to get segment duration from the recording object introduces inaccuracy because final spike time != recording end time? Obviously in most dense recordings this is a pretty minimal difference, but I'm not sure what the policy is more generally that you guys have been using to handle this
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hey Jake! Looking amazing, and feels much simpler than before - thanks for all the updates.
I think all my feeback is about computing durations of segments. Have a read of the comments in rasters.py
first, then the other stuff. Once that's sorted, this should be good to go!
for more information, see https://pre-commit.ci
for more information, see https://pre-commit.ci
@jakeswann1 can you apply the changes from Chris? We cannot push to your fork since you made the PR from main |
Thanks @jakeswann1 LGTM! @chrishalcrow wanna take a final look? |
One tiny change, then will approve :) |
Moved to #4035 so it can be merged properly |
Adds the option to pass a list of segment indices to the
AmplitudesWidget
,DriftRasterMapWidget
, andRasterWidget
to plot across multiple segments, by updating how the base widget handles plotting data. Maintains current default behaviour and SortingView capability. resolves #3801