Marius Pachitariu

I found the main bug in Kilosort 2.5 and 3. The batch size was manually changed inside trackAndSort (another ntbuff was added). The patch0 releases fix this.

If it works for you with the Matlab version of Kilosort2.5, you can see the two locations where I made changes in the trackAndSort script and adapt that for pykilosort.

Can you please check if an offset of ntbuff samples realigns the spikes?

I have fixed both bugs that were causing the spike holes problem, one in a CUDA file and one in a Matlab file. I think the spike times are correct...

@alejoe91 thanks, did you change ops.NT to the new value? Also, ntbuff should be 64 and nt should be 61.

The new default value for NT is 64 * 1024 - ntbuff. I can make that more clear in the release notes.

I didn't see it in my own test and it shouldn't behave differently unless I forgot something, can you please run a longer/different recording to see if it replicates? NT...

I'll take a look when I have time. 3.0.1 fixes the spike holes bug. Hopefully it did not introduce a time alignment bug. Could you please double check if this...

Yeah, there is a difference in how the first batch is treated for the buffer offsets. What I have to determine is if the spike times are correct (and the...

I have fixed both bugs that were causing the spike holes problem. I think the spike times are correct now, can you please check it in version 3.0.2 (new release)?