Skip to content

Rec group set to shank_id in NP 2.0 multishank, but to probe_id for NP 1.0 #449

@dkassybayeva

Description

@dkassybayeva

Hello!

SpikeInterface version 0.104.3

As I understand the recording group gets automatically assigned "probe" as group for NP 1.0 and "shanks" for NP 2.0 multi-shank.
This is not necessarily an issue, but created some confusion when sorting began and the single NP 2.0 4 shank probe got split into 4 separate probes folders.
My question is: is there a particular reason for this choice? Can I safely change grouping for NP 2.0 multi-shank probes to "by_probe" rather than "by_shank"? Will that lead to some issues downstream? Because I don't know if any other processing relies on these groups to be shanks and not probes.

Here is a recording with two NP 1.0 probes and property > group of this recording assigns IDs 0 or 1 for each probe:

Image

And here is a recording with single NP 2.0 multi-shank probe and property > group of this recording assigns IDs 0, 1, 2, 3 for each shank:

Image

Let me know if this info was specified somewhere and I missed it.

I'm also wondering what would happen if I were to have two NP 2.0 multi-shank probes in a single recording. What would group property assign and where would shank id information go?

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions