Attach ProbeGroup directly to recordings#4531
Draft
h-mayorquin wants to merge 21 commits intoSpikeInterface:mainfrom
Draft
Attach ProbeGroup directly to recordings#4531h-mayorquin wants to merge 21 commits intoSpikeInterface:mainfrom
ProbeGroup directly to recordings#4531h-mayorquin wants to merge 21 commits intoSpikeInterface:mainfrom
Conversation
This was referenced Apr 19, 2026
ProbeGroup directly to recordings via _probegroup
ProbeGroup directly to recordings via _probegroupProbeGroup directly to recordings
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Coming here from probeinterface #425.
This PR migrates SpikeInterface's recording layer from the flat
contact_vectorstructured array stored in_propertiesto aProbeGroupobject held directly on the recording.BaseRecordingSnippetsgrows a_probegroupattribute populated byset_probe/set_probegroupand propagated through every probe-retaining operation.get_channel_locationsreads positions fromprobegroup._contact_vector(the narrow handle from #425).SpikeInterface #4465 was developed assuming the fuller array-backed direction in probeinterface (probeinterface #420). This PR takes the same recording-side migration but pairs with the narrower probeinterface #425. The SI-side code ends up roughly the same shape either way; what changes is how much we ask probeinterface to absorb.
Three technical points:
ProbeGroupbecomes the canonical attached object. The legacycontact_vectorproperty is gone from the steady-state representation. All probe-retaining operations (set_probe,ChannelSliceRecording,ChannelsAggregationRecording,motion_interpolationremove_channels, dict-load) route through the canonical_set_probespath, solocationandgroupderive from the attached probegroup consistently rather than being maintained separately across code paths.Probe serialization stays in probeinterface. The recording's
to_dict()delegates toProbeGroup.to_dict(), and_load_extractor_from_dictrestores viaProbeGroup.from_dict(...). There is no recording-side format for probe state; the serialized representation matches the in-memory object. Derived properties likelocationandgroupare still written on the recording for backward compatibility and to keep the diff focused, but they are treated as cached views of the probegroup, not as the canonical representation.Old recordings still load. A
_restore_probegroup_from_legacy_contact_vectorhelper migrates the legacycontact_vectorproperty plus associated annotations (probes_info, planar contours) into the new representation on load, then drops the legacy fields.biocamandmaxwellextractors (which previously readcontact_vector["row"]/["col"]/["electrode"]directly) now read fromprobe.contact_annotations.