combine_probes lose 'device_channel_indices'

[chiyu1203]

I followed this doc to create a multi-shank probe.
However, the resulting two-shank probe does not has 'device_channel_indices'. Could anyone suggeset how to fix this issue?
I checked the function there was a comment at line 89 saying

# TODO deal with contact_ids/device_channel_indices

so I dont know what's the best way to approach this issue

probeinterface version 0.3.2

[h-mayorquin]

Sorry for the long wait for an answer. We are in the middle of a discussion on how to handle this. See SpikeInterface #4553, SpikeInterface #4397, and probeinterface #420.

The direct solution to your problem is to set the device channels at the ProbeGroup level.

multi = combine_probes([shank0, shank1])
combined = np.concatenate([shank0.device_channel_indices, shank1.device_channel_indices])
multi.set_device_channel_indices(combined)

The main problem is that device_channel_indices at the probe level are meant to be a local reference. They attempt to match an internal index of the probe data with the internal index of the would-be trace of a recording. They are meant to be properties of probes attached recordings, so the semantics for stand-alone probes are not clear and are riddled with ambiguities such as:

• A standalone probe has no recording attached, so device_channel_indices = [0..N-1] could mean "channels 0..N-1 of the recording it will be attached to" or "channels 0..N-1 of the recording it was loaded from." Nothing on the probe distinguishes them.
• Two probes each carrying [0..N-1] can be two shanks of one recording (need offsetting before combining) or two probes from two separate recordings (should not be combined at the probeinterface level at all). The arrays look identical.
• Probe.copy() drops device_channel_indices, combine_probes() drops them, but readers like read_spikeglx() set them. The field is treated as half probe-state, half recording-state across the API.

Setting them at the ProbeGroup level then is clean intent as you are stating that you know the index of the traces that would be assigned.

Be aware that if you are using SpikeInterface at recording time it will modify the information that you set (see SpikeInterface #4565), so there is no surprise. This still keeps the right mapping but does an internal reorder.

Tagging the other developers as they might have a different opinion than mine, and that is important: @alejoe91 @samuelgarcia @chrishalcrow