Association of spiketrains & analogsignals

[JuliaSprenger]

With the current neo structure, groups can be used to link to spiketrains and analogsignals, e.g. to associate data coming from the same recording electrode. However, this association is only accessible when starting from the group level and accessing data objects. It is not possible to navigate from a spiketrain directly to the corresponding analogsignal. The current workaround is to start from the block level and filter all analogsignals to retrieve the correct analogsignal. It would be much easier (and less compute intense) if an 'upward' link between a spiketrain and the groups it is linked to would exist.

We removed this link when introducing group & channelview instead of channelindex and unit as it is makes housekeeping and saving a neo structure more cumbersome. I think we might need to reconsider here as this is breaking / complicating many use-cases.

See also #588.

@samuelgarcia @apdavison @Kleinjohann What's your current opinion on that?

[samuelgarcia]

I agree. I must confess that I am not conviced by ChannelView... For me the link AnalogSignal<>SpikeTrain is something very specific due to spike sorting case. Maybe could be handle directly by a one-to-one relationship + specific key in array_annotation for channel mask.

[Kleinjohann]

Thanks for opening this, I was about to bring it up, too.

To me, linking SpikeTrains to AnalogSignals is an important use-case. As of now, the only way to take full advantage of groups for this is to traverse the neo structure via Block --> Group --> SpikeTrain and to store the group, which does not seem straightforward and is actually not applicable if SpikeTrains are accessed using e.g. Block.filter() or by looping over all SpikeTrains of a segment.

[JuliaSprenger]

@samuelgarcia So you are suggesting, that instead of introducing again an 'uplink' from a spiketrain to a group object, this link could be directly to a sort of channelview. I think this should be rather explicit, than implicit as it was for the channelindex, so I think we can solve this without introducing a channelview-type object...

[apdavison]

How about using weak references for the uplinks?

[jpgill86]

How about using weak references for the uplinks?

And with this in mind: #684 😉

[samuelgarcia]

We decided to implemented SpikeTrainList first and then to come back to this.