Error in ExtractParameters: referencing channel 384 when there are only 383 channels

[dervinism]

I am getting the following error:

Index in position 2 exceeds array bounds. Index must not exceed 383.

Error in ExtractParameters (line 153)
        [~,MaxChannel(uid,cv)] = nanmax(nanmax(abs(spikeMap(waveidx,ChanIdx,cv)),[],1)); %Only over relevant channels, in case there's other spikes happening elsewhere simultaneously

Error in UnitMatch (line 107)
[AllWVBParameters,param] = ExtractParameters(Path4UnitNPY,clusinfo,param);

Error in DEMO_UNITMATCH (line 106)
[UniqueIDConversion, MatchTable, WaveformInfo, UMparam] = UnitMatch(clusinfo, UMparam);

I assume this might be caused by me setting the following parameters like this:

UMparam.nSavedChans = 384;
UMparam.nSyncChans = 0;
UMparam.nChannels = 384;

rather than

UMparam.nSavedChans = 385;
UMparam.nSyncChans = 1;
UMparam.nChannels = 385;

because I don't have an extra sync channel.

Could you please advise me on how I should fix this issue in my case when there is no sync channel?

[EnnyvanBeest]

It seems that you have very different data than we do. Would you be able to send me some minimal data to recreate the problems you run into, so that I can see what needs to be changed for this specific case? If you could please share this via ennyvanbeest@gmail.com I will try to look at it asap.

[dervinism]

What would happen if you remove your sync channel and run the pipeline on your own data? That would be the quickest way to check this issue. Sharing two recording sessions of my own where you could try to track units would take more time.

[EnnyvanBeest]

From the error message you show it seems the problem is that spikeMap was 383 channels rather than 384. There was a piece of hardcoded code subtracting one channel, which I now replaced by the UMparam.nSyncChans on the work in progress branch.

I have two solutions for you:

1. You use the 'DEMO_UNITMATCH_OpenEphys.m' function to run the data - this demo was used to test data acquired on OpenEphys with phy curation, so very different data then what I typically have myself. Here the code worked perfectly fine, so hopefully it will do the same for you data. Please use the work in progress branch for now. If it works I can pull these changes to the main branch.

2. If solution 1 doesn't fix things for you, I can only attempt to replicate the bugs you find using the exact data you try it on. It seems you have changed the code/commented out mulitple things so at this point it's hard to understand for me why/how it's not functioning the way it should. This only has to be one session (I don't care about the tracking results, just want to make sure the code functions fine which can be done on one single recording): the KS output + raw data for one recording session - please choose the shortest one you have available (but >5mins of recording so that there are sufficient spikes).

Please let me know whether solution 1 worked, if not whether you want to go for solution 2, so that we can hopefully close this issue succesfully.

[dervinism]

Yes, the solution 1 worked. Thank you. I forked the code with changes here.

[EnnyvanBeest]

Thank you for the feedback, I will push the changes I made on the work in progress branch to the main branch.