Potential Problem in Trial Ordering

Hi guys,
When building the trial table, our trials get ordered incorrectly because all of the individual dat files get sorted on their datenum property [here](https://github.com/AllenNeuralDynamics/ophys-slap2-analysis/blob/3e4ffcacba6c924eb4fe53b36f9b9054f105fd90/matlab/preprocessing/buildTrialTableSLAP2.m#L130).

We acquire our data using the SLAP2 control/acquisition machine, then copy that data to our network-attached storage devices. All processing is done via a server with a high-speed connection to these NAS devices. The .datenum property on these files seemingly corresponds to when the data was successfully copied to its current location, not when the original file on the acquisition machine was created - so when we sort on this property, the resulting sortorder is completely scrambled.

I have a feeling that this is idiosyncratic to us and has something to do with how we are transferring or reading the data, which is why you guys probably haven't noticed it, but thought I would log this here in case anyone else ever runs into it. The simple fix is to just sort on the file name, which itself contains the trial number. Replacing the line linked above with this should do it:

`[~, sortorder] = sort({DMD1files.name});`

I haven't traced this through the entire pipeline, and it wouldn't be too hard to just correct for it after the fact and reorder the trials correctly, but to confirm that the trials do in fact get scrambled, the below image shows the matchFilt traces from a single source of a 1 minute continuous recording (6 consecutive 10-second trials). The only difference in the processing between top vs bottom was that single line (and the equivalent for DMD2) being changed.