Using SpikeSorter Version 5.0

 

 

Quick start

 

(this will not work for all file formats – see next section)

 

1. Read in a high-pass filtered data file.

2. Go to Sort then Autosort then press ‘Start’.

3. When finished, press ‘Next’ and proceed to the guided merge step as prompted.

4. Examine clusters with Review→Compare pairs and/or with Review→View, Clean and Split Clusters

5. Go to Export→Sorted Spike files to save the sorted data.

 

This is optimistic but not entirely unrealistic.

 

Recommended way of starting

 

Channel locations and the config file

Many file formats do not include information about channel locations, although this information is essential for sorting. Those formats that include, or do not need, channel position information include single and multi-tetrode (.ntt and .ncs) recordings, and MultiChannel Systems (.mcd) files. Neuropixels SpikeGLX recording files have their own separate electrode geometry files which are described below. For other file types you will need to create a file which contains this information before you can do anything further. This file is called a channel configuration file. SpikeSorter needs to be able to link this file to the specific data file that is being sorted. There are two ways to do this. If all the files in a given directory have been recorded with the same electrode and channel mapping, you can use a single file, called ‘electrode.cfg’ to store the values. Alternatively (or in addition) you can use a file with the same name as the data file, but with the extension ‘.cfg’. For example, a configuration file specific to the data file ‘H4012.plx’ would have the name ‘H4012.cfg’. If both files are present, SpikeSorter looks for the more specific of the two possibilities first. In all cases the configuration file has to be in the same directory as the data file.

 

The configuration file is in ascii. The first line gives the electrode name and must be 10 bytes or less in length. Subsequent lines, one for each channel give, in order, a) the number of the channel as used in the data file; b) a unique channel number, in the range 1 – max_number_of_channels that SpikeSorter will use to identify the channel; c) the horizontal, x-coordinate, in microns, of the channel, and d) the vertical, y-coordinate, in microns, of the channel. A sample file for an array of 4 tetrodes would look like this when printed out:

 

quadTet

       1       1       0      50

       2       2      50       0

       3       3       0     -50

       4       4       0     200

       5       5     -50     250

       6       6     -50       0

       7       7       0     300

       8       8      50     250

       9       9     -50     500

      10      10       0     450

      11      11      50     750

      12      12      50     500

      13      13       0     550

      14      14       0     800

      15      15     -50     750

      16      16       0     700

 

You can create this file in any kind of text editor, e.g. Notepad or export it from Excel. Make sure the last line of the file is terminated, i.e. has a carriage return.

 

 

Neuropixels Files

Neuropixels SpikeGLX binary data files (.bin + .meta) require an auxilliary channel data file called ‘geometry.txt’. This file is in ascii, and contains the (x, y) channel locations, in microns, in order of channel number, one channel per line. The file will be similar to the electrode.cfg file, except that there is no initial line with the electrode name, and the first two columns (which remap the channel numbers) are absent. The last line in the file should be terminated with a carriage return. The number of lines in the file should match the number of spike channels in the accompanying .bin file. If it does not, location data will be missing for some channels and sorting will not work properly. Note that sync channel data, if present, is not read in.

 

Tools for extracting channel location date from SpikeGLX files have been written by Jennifer Colonell and can be found at:

 

https://github.com/jenniferColonell/Neuropixels_evaluation_tools/blob/master/SGLXMetaToCoords.m

 

https://github.com/jenniferColonell/ecephys_spike_sorting/blob/master/ecephys_spike_sorting/common/SGLXMetaToCoords.py

 

They may be helpful in creating the geometry.txt file.

 

The geometry.txt file should be kept in the same directory as the data file. Data files that use different electrode channel locations will need to be kept in separate directories, each with their own geometry file.

 

Neuropixels SpikeGLX files have an emprirically measured, floating point, sampling frequency. Exported spike times will be calculated using this non-integer value. It should be possible to recover the index (sample point) values for these exported times by multiplying by the sampling frequency.

 

 

Preliminary steps

After reading in a data file, examine the recording waveforms (double left-click on the waveform display to bring up a dialog that allows you to scroll through the recording and channels). Single left click on a waveform and the voltage at the cursor location will be displayed at the top of the window. If the file contains unfiltered 16-bit data you will need to apply a high-pass filter to remove the low frequencies. To do this, go to Pre-Process→Transform, select ‘High-pass Butterworth filter’ with (the recommended) default settings of f0 = 0.5 KHz and 4 poles. ‘Removal of the common mean’ is also an excellent option for recordings with many (> 30?) channels. This will remove noise that is correlated across all the channels for each time point. After filtering you may wish to save the values in a new data file in order to avoid having to run the filter every time the file is read. Go to Export→Sorted Spike Files to do this. Not all file types can be saved in their original format but there are alternatives (see below). Do not overwrite original data files when doing this.

 

 

Masking faulty channels

Next, you may need to identify and mask non-functional electrode channels from further processing. Examination of the voltage record may allow visual identification of non-functional and/or noisy channels. Once you know what these are, you can go to the Pre-Process→Event Detection menu. Use the vertical channel slider control (top right) to scroll through the list of channels. The ‘Auto’ button will apply a pre-defined threshold to the voltage standard deviation measurements to identify grounded channels, but this may not always do what you want. Another option if you have continuous recording data is to go to Pre-Process→Channel check and let this identify possibly faulty channels for you.

 

You will be prompted to save a mask file on exiting the relevant dialog if new mask settings have been applied. Mask files have the same name as the corresponding data file but with the extension ‘.msk’. You will be prompted to read the mask file, if it exists, the next time the data file is read. Masked channels are greyed out in the displays and excluded from event detection and clustering routines.

 

 

Event detection

After setting masks, an appropriate event detection method (Pre-Process→Event Detection) should be chosen. For continuous recordings with MEAs where channels are close enough together that spike signals are likely to be present on more than one channel, the recommended method is ‘automatic’ thresholding together with the dynamic multiphasic filter and the proto-event clustering method for avoiding duplicate events. Alternatively, a variable (noise multiple) threshold in the range 4 – 6 can be used. Window widths should be comparable to the width of the spikes in the recording. Too narrow a value may result in broader width spikes being missed. For event-based recordings, where only voltage snapshots are present, it may be best to use a uni- or bi-polar detection method with fixed voltage thresholding. 

 

Avoiding duplicate events

An important aspect of event detection with continuous recrdings is avoiding the detection of two events from different parts of the same spike (referred to as ‘duplicate events’). This has to be balanced against the need to resolve spikes that are close together in space and time. Two methods are offered by SpikeSorter for doing this. One is called ‘Proto-event clustering’ (PEC) and the other ‘Spatio-temporal lockout’ (STL). PEC is the better of the two methods, but is slightly slower and uses lots of memory. This may be a limitation for long recordings with large numbers of channels. If you get memory error messages with PEC it will be better to switch to STL instead. More details about the two methods can be found here: https://swindale.ecc.ubc.ca/wp-content/uploads/2020/09/spike_detection_polytrodes.pdf

In both cases, appropriate spatial and temporal windows need to be specified. They should be as small as is possible, consistent with avoiding duplicates.

 

Event alignment

Once an event is detected, a detection time has to be assigned to it. This should be based on a consistent feature of the spike waveform, such as a peak or trough. If all your spikes have well defined negative troughs, use that option. If not, other good options are ‘largest peak/trough’ or ‘v2 weighted c.o.g.’ (center-of-gravity).

 

Once you have run event detection you should inspect the detected events using the View→Voltage Record display. Make sure that large spikes do not result in more than one event being detected and that spikes that are close together are resolved. Duplicate events however can often be detected and removed later on. If nearby spikes are not resolved, use smaller window settings for the STL or PEC methods, as appropriate. If there are duplicates, do the reverse. Note that the settings chosen in this dialog will be applied when you run the Autosort option.

 

 

Autosort

After masking and choosing the best event detection options you can run the Sort→Autosort procedure. This has 4 stages: (a) event detection (possibly already done); (b) formation of one initial cluster per channel followed by splitting this set into as many as possible based on the principal components (PC) distributions; (c) merging of cluster pairs whose PC distributions overlap substantially and (d) a merging and resplitting stage where cluster pairs whose PC distributions overlap partially are reclustered, i.e. events are swapped between clusters to give less overlap of their PC values. Most of the options offered in this dialog can be left at their default values. Make sure the ‘Template window’ settings comfortably include the bulk of the spike waveforms for all the units. You should also choose an appropriate template alignment option under ‘Realignment’. The reason for an additional alignment option at this stage is as follows. After event detection, events can only be aligned based on the shape of each individual event. Following clustering however, the average of the event waveforms in a cluster – the template – can be used as a basis for alignment that is much more robust than the shapes of the noisy, individual events. Events are always matched to the current template by shifting them so as to minimize the difference between the event and the template. This is done routinely following the calculation of the template for a given cluster. Next, just like individual event waveforms, templates can be aligned (i.e. a central zero, or anchor point, chosen) based on specific features such as the largest negative trough, the peak or the mean position (center-of-gravity) of the template waveform. The recommended option is the ‘peak-weighted c.o.g.’, however, depending on the characteristics of the spikes, other features might work well. Other adjustable parameters include the minimum cluster size (clusters smaller than this will be deleted, including intermediate ones) and the clustering threshold. Minimum cluster sizes between 25 and 100 are recommended, and values of 8 or 9 for the clustering threshold. Smaller numbers will tend to result in more clusters and vice versa.

 

Alignment may seem like a fussy (and sometimes confusing) detail but it can have a critical effect on the distribution of principal components values and the ability to separate units based on subtle differences in spike waveform shape.

 

Guided Merge

After the Autosort procedure is finished, SpikeSorter asks you, in a procedure called the ‘Guided Merge’, to examine pairs of clusters that it considers problematic and which may need to be merged, or merged and then re-split. You make these judgements based on your examination of the waveform shapes of the two clusters, the distributions of their PC values, and (optionally) on changes in the waveform shapes over time and on auto- and cross-correlations of the two spike trains. At the end of this procedure clusters will be labelled as ‘stable’, meaning that the cluster is considered to be distinct from every other cluster in the sort, or ‘unstable’, meaning that the cluster cannot clearly be separated from at least one other cluster in the sort.

 

 

Pair comparisons and post-processing

Following the guided merge, it is a good idea to continue to examine pairs of clusters using the Review→Compare Pairs option. This allows you search serially through pairs in order of a variety of match criteria, including spatial separation and rms waveform difference. You may also want to clean or manually split clusters – use options in Review→View, Clean and Split Clusters and Review→Post-processing. Other post-processing options include re-assigning events to clusters that may have become lost during the first stages of sorting (but judgement needs to be applied to accepting the results). You can also delete low signal-to-noise clusters or clusters with less than a specific number of events in them. Clusters can be renumbered according to various criteria, e.g. the largest cluster can be #1 etc..

 

 

Autorecover and autoresume

SpikeSorter has a crash recovery procedure (parameters can be changed in the Preferences dialog). The extent to which you can recover from a crash will depend on the state the program was in when the last autorecover file was saved. Unfortunately, it is not possible to resume from most intermediate stages of the Autosort. The autoresume feature, if used, should return you to exactly the state the program was in when you exited.

 

Some of the above information is repeated in the following sections.

 

 

Overview of Menu Bar Options

 

File

As well as reading data files, you can save your work, i.e. the current state of the program, in a work file. Work files will usually (but don’t have to) have the same name as the data file, with the extension ‘.wrk’. Reading in the data file and then the work file will restore the program to the state it was in when the work file was saved. It is recommended that you save a work file immediately after a sort, and also immediately before or after exporting sorted spikes. There is an option for doing this automatically. The work file saves information about any filtering that was done and will prompt you to repeat it.

 

The Preferences dialog allows changes to be made to parameters that affect the displays but have no effect on sorting. When you first start using SpikeSorter you may have to make adjustments to suit the kinds of data you are looking at, the channel layout, signal amplitude, screen size etc. Changes made via this dialog are always saved on exiting SpikeSorter or when the ‘Apply’ button is pressed. Note that if the Sticky parameters option is selected, the values of other user-selectable parameters that do affect sorting will be preserved each time SpikeSorter is run. This has the consequence that changing a value (e.g. of a threshold) results in that value being inherited the next time the program starts. If the Sticky parameters option is not selected, parameters are set to the same default values each time the program is started.

 

Automatic choices of window sizes and positions can be made by going to ‘Windows – autoarrange’. (Using the ‘maximise’ option on individual windows is not recommended.)

 

View

These options allow you to look at the data non-interactively, e.g. the raw voltage record, the sorted spike waveforms and a summary of the sorted data.  Most of these display options should be self-explanatory and/or easy to explore.

 

Pre-process

As mentioned above, Transform/filter allow filtering of the raw voltage data (essential if you are using unfiltered 16-bit waveforms). Various other smoothing and filtering procedures are offered. Subtraction of the common mean is often useful but the other smoothing procedures, though they may make the recordings look nicer and less noisy, have never seemed to improve sorting in my own experience.

 

Channel check offers a semi-automated method for identifying and masking shorted or faulty channels.

 

A variety of Event detection options can be chosen. As discussed above, the recommended method for most continuous recordings is the dynamic multi-phasic filter, together with proto-event clustering and automatic thresholding. Note that proto-event clustering requires additional memory and might cause problems with very large files, in which case the simpler spatio-temporal lockout procedure can be used instead. The event detection dialog also allows faulty channels to be masked from processing. Mask values are saved in a file with the same name as the data file and with the extension .msk, and are read in automatically with the data file. There are various options for aligning individual events following detection. Alignment means choosing the exact time at which the event can be said to have occurred. The best option to choose depends on the characteristics of the spikes. Aligning to the negative trough may be the best choice if the majority of your spikes have well defined negative deflections. Other generally safe options are ‘largest peak/trough’ or ‘v2 weighted c.o.g.’ (center-of-gravity).

 

 

Sort

Autosort is the main automated sorting procedure offered by SpikeSorter. It is recommended that most of the options are left at their default settings, possible exceptions being PC dimensions (maybe 3 instead of 2) and clustering threshold (values in the range 7 to 9 are recommended). You can also decide on a minimum cluster size. Values around 25 – 50 are recommended but larger values may be appropriate if you are not interested in small clusters. Note however that clusters are often broken into parts during sorting and these individual parts may be deleted if their size falls below the minimum value.

 

When the Autosort is finished, click on ‘Next’ to go automatically to the Guided Merge step. In this procedure, clusters are presented in pairs and you have to decide whether to merge them, label them as distinct, or whether to combine them and re-split into two (or occasionally more) distinct clusters. Clusters pairs for which no clear decision is possible can be manually labelled as ‘ambiguous’ and are defined as ‘unstable’. A cluster will be defined as ‘stable’ if it is clearly distinct from all other clusters in the sample. Ideally, all clusters will be stable at the end of the guided merge stage but this may not always happen. Sometimes there are no unstable pairs following Autosort, in which case there will not be a guided merge step and you can proceed directly to inspection and post-processing steps. Note that pairs might still have to be merged based on manual inspection, e.g. if spike shape changes significantly over time, or in cases where there is a large effect of small inter-spike intervals on spike shape. Methods for detecting these effects are available in the Compare Pairs dialog described below..

 

The Guided Merge process normally starts at the end of the Autosort procedure but, once the autosort step is finished, can be started, interrupted and restarted at will. However, status lists (match and overlap values for all cluster pairs) have to exist to begin with. These are normally created at the end of the Autosort. You can create (or recalculate) these lists by going to Sort→Make Status Lists. After that you can go to Sort→Guided Merge/Split to begin or continue the procedure. Status lists may need to be manually updated after some procedures (e.g. after recovering lost events, or deleting noisy events) however they should be automatically updated after manual cluster splits, merges, or reordering of cluster numbers.

 

Following event detection, Convert channels to clusters will form a single cluster for each channel comprising all the events registered to that channel. Subthreshold-sized clusters will however be deleted. This can be used as a prelude to manual clustering (avoiding Autosort entirely) and can also be a useful way of seeing what kinds of clusters are present on each channel (go to View, Clean and Split Clusters immediately afterwards.)

 

The Strategy dialog allows changes to be made to low-level sorting parameters, most of which should probably not be changed. One exception to this is the value of cluster overlap used to define pairs as distinct. This parameter can also be changed in the Autosort dialog. Values in the range 0.1 – 0.15 seem appropriate. A higher value results in more tolerance of overlap and a lower value results in less tolerance plus possibly extended sorting times but potentially cleaner sorts. Another parameter that might be experimented with is the method used to select points for PC analysis. ‘Voltage plus Gradient’ and 50 points has proved to be a consistently good choice but other methods and numbers might have advantages. One way of testing this might be to run only the first stage of the autosort procedure (minus the final merging and splitting stages) and see how many clusters result. The method that produces the most clusters is probably the best one (oversplitting can be dealt with later on).

 

Beware that, if the ‘sticky parameters’ option is selected in ‘Preferences’, the strategy parameters will also be saved and used the next time the program is run. Strategy parameters are also saved in work files, independently of the sticky parameters option. Therefore when you read a work file, its strategy parameters will continue to be used unless overwritten by another work file, or you change them back manually. If sorting is going wrong for no obvious reason it might be a good idea to check the values of these parameters, and if necessary return them to their default values.

 

Review

These options allow you to inspect, clean and split single clusters (View, clean and split clusters); to compare cluster pairs (Compare cluster pairs); to examine cross- and auto-correlograms of spike trains (Auto/cross-correlation); and to Realign or Recalculate templates. Spatio-temporal spike view is an interesting way of examining units, especially for large electrode arrays and retinal recordings. Post-processing offers various procedures for removing duplicate events, identifying events that are perhaps spurious and for restoring events that have been lost during sorting.

 

The View, Clean and Split Clusters dialog offers various options for manual, or semi-manual splitting of existing clusters. Manual clustering based on spike waveforms can be done by drawing one or more windows (use the right mouse button) in the view cluster waveforms display. These work like a window discriminator – waveforms have to pass through every window to be accepted and those waveforms that fail this test will be placed in the first subcluster (normally coloured red). Windows can only be drawn when the dialog is exited – double click on the display to bring up the dialog again. Pressing the ‘Windows’ button will apply the test. An ellipse can also be drawn, resized and moved in the Principal Components display window (again the dialog must be exited to do this). Press the ‘Ellipse’ button to apply the clustering. A rectangle can be drawn in the P-P height (or PC1 or PC2) vs time window. Likewise, press the ‘Rectangle’ button to apply the clustering. Finally the ‘Autosplit’ button will apply a full scan of the gradient ascent clustering procedure to create clusters, while the ‘Fixed split’ button will perform a single scan with a fixed sigma (spatial bandwidth) value. These procedures create sub-clusters which can be deleted or split with the appropriate buttons to create new clusters. The ‘Reclaim lost events’ button will search for and recluster unclustered events which have been deleted during sorting, perhaps because the spike is spread over several channels resulting in an initial sub-threshold sized cluster which got deleted. (Other possible reasons have not yet been identified). This is a new feature and, sometimes, substantial numbers of events can be recovered. Recovered events are given a sub-cluster number of 1 and can be identified separately in the display. They can also be deleted. It is suggested that you use the ‘Reclaim’ feature cautiously.

 

The Compare cluster pairs dialog allows comparison of cluster pairs with the aim of further determining how distinct they are. Pairs can be merged or re-split with the aim of making them more distinct. Because there is potentially a large number of pairs to look at, ordered lists of pair are created on the fly based on a selected match criterion. The various options include template correlation, cluster overlap, spatial separation and others. Choosing e.g. spatial separation will order the pairs in terms of the estimated physical distances between the units. The pair that is closest together will be the first in the list. ‘Rate complementarity’ is a good way of finding and merging pairs that exist because the spike waveform changed slowly over time. ‘Doublet pairs’ is a good way of identifying cases where spikes tend to fire in groups with the first spike being larger than subsequent ones, resulting in over-splitting. This may be manifest as a very narrow and asymmetric peak in the cross-correlogram for short time intervals. Various ways of examining the similarity are offered including displays of waveforms, template shape, plots of spike height or PC value vs time and cross and auto-correlograms.

 

Post-processing allows deletion of duplicate events (usually caused at the event detection stage); alignment cleaning (usefulness remains to be fully explored); reclustering of events wrongly deleted from clusters (this is the same ‘Reclaim’ procedure offered in the View, Clean and Split clusters dialog, but applied to all the clusters); deletion of clusters based on signal-to-noise ratio and renumberng of clusters according to criteria such as spike height, channel number or position on the electrode.

 

 

Supported file formats

These currently include Plexon (.plx), Neuralynx (.ntt and .ncs), Blackrock (.nev and .nsx), Multi Channel Systems (.mcd) files, Intan (.rhd) and Neuropixels SpikeGLX (.bin + .meta) files. Multi Channel Systems files use the Neuroshare interface which requires the file nsMCDLibrary64.dll to be present in a location where SpikeSorter can find it. If Multi Channel Systems software is installed, the file may already be present and in the correct location, if not, obtain a copy and put it in SpikeSorter’s home directory. Multi Channel Systems will update this file as required to make it compatible with changes in the format of the .mcd files.

 

HDF5

Support for reading files in hierarchical data format (HDF5) has recently been added. Because of the generality of HDF it is not possible to know in advance where in a file particular data values will be stored without extra information. An interface is therefore provided which will require you to navigate to the node in the file where the relevant recording data are stored. The file types I have examined - MCS and neurodata without borders (NWB) – have not appeared to include channel location data, hence a channel configuration file will need to be created for these and, at present, other hdf recordings. Nor is it always clear where to look for the values for voltage scaling and sampling frequency, the latter being an essential parameter. MultiChannel Systems .h5 file format does allow automatic retrieval of sample frequency and voltage scaling parameters, however for other types of hdf files you will have to enter these values manually each time the file is read. Once you have read an hdf file, and if needed, filtered it, it may be easiest to save the data in SpikeSorter’s native .tsf format. This will contain all the relevant parameters including channel locations and will not need to be filtered each time it is read. Based on my experiences, I cannot recommend HDF5 as a file storage format. For a more developed perspective on this see https://cyrille.rossant.net/moving-away-hdf5/

 

Note that SpikeSorter’s cluster IDs (from 1 upwards) will generally not be preserved across saves and reads of data formats that store channel-based cluster numbers (i.e. cluster IDs that begin at 0 for each channel). This includes many of the commercial formats.

 

I am always happy to add new data formats to SpikeSorter, or to improve/debug/update existing file reading code, so please get in touch if you have issues reading files or if you would like support for a specific file format.

 

Export

Data can be saved (i.e. event times and cluster IDs) in a variety of formats. Plexon (.plx), Neuralynx (.ntt) and Blackrock (.nev) formats include the original voltage data along with the sorting results. There is the option of overwriting the original values with new ones if the voltage values have been changed by filtering: it may be best not to overwrite original data files with new data in such cases. It is also highly advisable to check in advance that files saved by SpikeSorter are readable by the software that produced them – there was an issue with this with Plexon files which may have been resolved but possibly not. The .tsf format is native to SpikeSorter but is a useful, and fast, way of saving continuous recording voltage, electrode channel and sorting data in a single file. Information on the format is provided separately. You can export spike times, channels and cluster IDs to a Neuroscope .evt format text file. Each line of the file contains, in order: the time of the spike in msecs (to 2 decimal places, i.e. 10 μs resolution), SpikeSorter’s channel ID and the cluster ID (0=unclustered). (Note that spikes in the same cluster might have different channel IDs.) You can also export to .csv files and individual files, one per unit, containing the spike times. Times in these files are given in seconds, with sub-millisecond resolution. Time is always relative to the start of the recording, i.e. the first voltage sample.

 

Representing time

Internally, SpikeSorter represents spike/event times as a combination of an integer sampling point value, with the first sample in the data having a value of 1, plus a fractional offset (a value between 0 and 1) in sample point units. (For most practical purposes this offset will be too small to matter but it is important during sorting). Hence, exported times are (necessarily) based on the sampling frequency clock and synchronisation of spikes with external events will require appropriate interpretation of these clock times. The integer indexes can be recovered, if needed, by multiplying the exported event times (in seconds) by the sampling frequency. Four byte integers are adequate for this task (allowing up to 19.8 hours of recording at 30 KHz).

 

 

Hardware

Recording voltage values are read completely into memory. If you have a 10 GB data file you will, ideally, need at least 10 GB of RAM plus another 2 GB for the arrays and code used by SpikeSorter. If you do not have enough memory, Windows may use virtual memory instead. This might work but it is also likely to slow things down unacceptably and/or make the rest of the computer unusable.

 

Much of SpikeSorter is multithreaded, using the OpenMP libraries (this option can be turned off) hence it will benefit from being run on a CPU with many cores.

 

 

Ancillary Files

SpikeSorter creates the following ancillary files in the home directory (the one the program is in):

 

Name                                       Function

ss.ufl                                        recently used file list

 

ss_prefs.sav                             saves user display preferences (window sizes, subcluster colors, etc.) not having any direct impact on sorting

 

ss_parameters.sav                    saves ‘sticky’ parameters, if ‘sticky parameters’ option is on. These are the majority of user-selectable options affecting event detection and sorting including ‘strategy’ parameters. Parameters are saved when SpikeSorter is exited normally.

 

ss_autorecover.sav                  temporary file saving crash recovery information, which is deleted on normal exit. Recovery information is saved at intervals determined in the user preferences dialog. The file contains a pointer to the original data file, a record of any filtering operations performed on it and the complete set of parameters used to do the sort. Resumption may however not always be possible depending on when the crash occurred (e.g. during the Autosort procedure

 

ss_restart.sav                           A file with the same format as ss_autorecover.sav which can be optionally saved on exit from the program allowing resumption of sorting from an identical state at a later time.

 

 

Papers

SpikeSorter implements the procedures described in these papers:

 

Clustering and sorting algorithms:

https://swindale.ecc.ubc.ca/wp-content/uploads/2020/09/Swindale_Spacek_Spike_Sorting_Frontiers.pdf

 

Event detection:

https://swindale.ecc.ubc.ca/wp-content/uploads/2020/09/spike_detection_polytrodes.pdf

 

https://journals.physiology.org/doi/full/10.1152/jn.00633.2020

 

Channel integrity checking:

https://swindale.ecc.ubc.ca/wp-content/uploads/2020/09/MEA_channel_verification.pdf

 

A Visual Guide to Sorting Electrophysiological Recordings Using 'SpikeSorter'

https://www.jove.com/t/55217/a-visual-guide-to-sorting-electrophysiological-recordings-using

 

Note that algorithms used in the program have been upgraded and improved over the years and may not correspond exactly to the procedures described in the papers.

 

Homily

Spike sorting is more of an art than a science and it is likely to remain that way for some time. There is unfortunately no way of knowing objectively whether one sorting procedure is better than another, even though there may be lots of suggestive indications. For all we know, some neurons may be capable of routinely generating spikes with a variety of shapes (perhaps anti- vs. orthodromic), while the extracellular waveforms of neurons that are very close together may often simply not be distinguishable in the presence of unavoidable sources of noise. This seems very likely to me in the cortex where cell bodies can abut and be as little as 10 µm apart. One behavior will lead to over-splitting and the other to under-splitting. In the face of difficulties for which there is no obvious practical solution I suggest it is better to come to terms with the fact that no sort is likely to be perfect and that it is better to accept imperfection and move on and see what the data suggest while realizing the limitations. I hope you will continue to refer to sorted units as ‘units’ and not ‘neurons’ – a distinction that was instigated many years ago and still seems important to me to maintain.

 

Disclaimer

While much effort has gone into testing the various functions of SpikeSorter to make sure it will work as might be expected, I can give no certain guarantee that it is free of bugs or inaccuracies. Please do not take correctness for granted and always make your own checks that the program is performing correctly. If mistakes are found, please let me know as soon as you can and I will be happy to do my best to correct them but I cannot accept responsibility for the consequences of these mistakes.

 

 

Nicholas Swindale

February, 2022