EGI/MFF events outside EEG recording should not break the code #11505
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Some EGI events can be outside (before or after) the EEG recording. E.g. for video-synchronization markers or "IEND" codes. In this case, the code breaks with an "index out of bounds" error. Examples are shown in the forum: https://mne.discourse.group/t/index-error-when-trying-to-read-data/2823 https://mne.discourse.group/t/index-error-while-reading-data/5535 I had a similar issue with an EEG with video segments terminating later then the EEG recording.
The edits here should make sure to skip events that are placed illegally, i.e. below 0 (see forum example) or after the EEG end (other forum example+my case). This edit fixed the problem for me and should not harm the usual function. However, out-of-bounds events will be skipped/lost. As alternative, the length of the events array could be extended for out of bounds events, but this may cause other issues with synchronizing to the EEG data.. Hence this option seems preferable. A warning may be added to notify the user of why an event was skipped.
Thanks for contributing a pull request! Please make sure you have read the
contribution guidelines
before submitting.
Please be aware that we are a loose team of volunteers so patience is
necessary. Assistance handling other issues is very welcome. We value
all user contributions, no matter how minor they are. If we are slow to
review, either the pull request needs some benchmarking, tinkering,
convincing, etc. or more likely the reviewers are simply busy. In either
case, we ask for your understanding during the review process.
Again, thanks for contributing!
Reference issue
Example: Fixes #1234.
What does this implement/fix?
Explain your changes.
Additional information
Any additional information you think is important.