Adding support for Nicolet .e files

[MureziCapaul]

The reader for .e files as mentioned in #1510

[MureziCapaul]

@h-mayorquin , @zm711 , @samuelgarcia
I have contacted the sales rep, and he sadly was not able to help me. I will now contact both the company itself and the original authors of the MATLAB version, maybe they can help me.

Also, I am already using the module and have discovered some errors and fixed them in my version which I will push on my fork and will be included in this pull request.

I think it makes most sense to wait for the responses, and then you can do the code review.

[h-mayorquin]

Thanks, please pin us once you have the responses and this is ready for review.

[MureziCapaul]

Dear @zm711 , @h-mayorquin , @samuelgarcia
I contacted the developers of the Matlab modules some time ago. They responded quickly, saying neither of them had file specifications. They essentialy reverse-engineered the file using a hex-editor and some knowledge of the data structure. One of the maintainers provided me contacts of the developers of the company that developed the EEG-Systems. I contacted tow of them, but neither responded in over a month. I think it's fair to say that I will not be able to get hold of file specification.
So shall we continue with the pull request?
Since my last comment, we have been using the module in our center and I added some small fixes and improvements.
Also, I have almost 100 commits. Would it be possible to enable squashing for pull requests so the module becomes a single pull request? (https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/configuring-pull-request-merges/configuring-commit-squashing-for-pull-requests)

[h-mayorquin]

So shall we continue with the pull request?

Is this ready to be reviewed now?

Would it be possible to enable squashing for pull requests so the module becomes a single pull request

+1

[MureziCapaul]

@h-mayorquin , sorry for the delay. Yes, it is ready to be reviewed now.

[MureziCapaul]

@h-mayorquin Hi, I just wanted to ask about the current status of the pull request? Have you been able to finish code review? There are also some merge conflicts. Will you resolve them, or should I do it?

[h-mayorquin]

Hi @MureziCapaul, sorry for the long silence here, and thanks for the nudges. I got back this and I've stubbed the file to a CI-friendly size and will put it on the ephy_testing_data gin repo once I get another PR merged, so the tests here can run. I also pulled the MATLAB ieeg-portal/Nicolet-Reader you ported from (plus a second multi-segment .e) to check against.

I took a first pass and those are two comments:

1. Event/epoch times look like they come out scaled by the sampling rate. In _get_event_timestamps the timestamps and durations get multiplied by sampling_rates[seg_index][0] (so they're in samples), but _rescale_event_timestamp / _rescale_epoch_duration only .astype() without dividing back so the final times end up in samples rather than seconds (e.g. an event at 4 s in a 256 Hz file reports as 1024). The MATLAB reader keeps these in seconds (it uses etime(...), and stores duration as a float64 in seconds), so I think dropping the * sampling_rate is all it needs — that also fixes the t_start/t_stop filtering in the same method, which is currently comparing those sample values against second-valued bounds.

2. Small one in _parse_header: signal_buffers is built as np.array(["Signals", "0"], dtype=_signal_buffer_dtype). With the two-field dtype, numpy broadcasts each string across both fields and you get two records (('Signals','Signals') and ('0','0')) instead of one. A list-of-tuples fixes it: np.array([("Signals", "0")], dtype=_signal_buffer_dtype).

Neither is a big lift and the reader is clearly close. More to come, and thanks again for sticking with it.