Specify an Alternate Event Files in Functions Like mne.io.read_raw_nirx

Like many other labs I’m sure, our triggers were not originally set up correctly to record in NIRStar all of the events that PsychoPy has intended, and so I’ve gone and generated (from the PsychoPy output) a new custom .evt file. I’d like to be able to read in these events using mne.read_events, but this function does not accommodate for NIRx systems or .evt style files, which the NIRx io function is reading. It is trivial to replace the old .evt files, except I would like to keep the original .evt files as well, side by side.

This could be accomplished with an optional keyword parameter in mne.io.read_nirx, which, when set, replaces the line expecting the filename prior to “.evt” to the custom parameter setting.

On this page: https://github.com/mne-tools/mne-python/blob/maint/1.0/mne/io/nirx/nirx.py#L26-L51

we would include:

1. optional parameter in read_raw_nirx, alt_evt=None
2. pass the param to RawNIRX ?
3. under the comment “read triggers from event file” line ~ 441: if alt_evt is not None: files['tri'] = alt_evt+".evt"

This alone should accomplish this feature.

Describe possible alternatives

If you’ve suggested an implementation above, list here any alternative implementations you can think of, and brief comments explaining why the chosen implementation is better.

The alternative solution would be to build out the read_events file to accommodate .evt style files. This may be beneficial, but from the documentation it appears that they only accept .fif currently, a changing format that might be hard to stay compatible with.

Open to other alternative solutions!

[larsoner]

So far the way we’ve handled “optional/other annotation-like files” for other readers is by making read_annotations support reading those files, then letting people do raw.set_annotations or raw.annotations.append(...). Since the .evt show up as Annotations in the raw data, I think it makes sense to live in read_annotations.

[claytonjschneider]

Ultimately, @larsoner this is preferable! I’m going to start work on a fork now to try to implement this.