Telling apart event-locked vs consecutive epoching

[mmagnuski]

Discussion

One problem I am currently having is how eegDb.epoch should work. It should have short, decriptive fields that work for onesecepoch and/or classical epoching.

currently the assumptions are:

1. locked informs whether onesecepoch is used. When locked is false it means we use epoching that is not event-locked. If no other fields (winlen, distance, etc.) are present this is the only field that differentiatiates whether onesec epoching is used.
   • If locked is false and there are no other fields, default onesecepoch options are assumed
   • if fields are present and do not agree with locked - the user is asked for it OR the locked is changed to match field values

:question: Default onesec options could be filled by some function (or option in buildbase?) for example consec_windows(eegDb) :question: Use subfields epoch.locked and epoch.consec

In menu use consecutive windows instead of onesecepoch - this would be more meaningful. (or some other name - any suggestions?)

Tasks

• [ ] check how recent ICAw_checkepoch (or something like this) checks epoching
• [ ] write some code that takes care of keeping epoch field in line with assumptions

[mmagnuski]

just reminding myself that this may be important when tracking whether onesec should do its work or if it's already done and present in reject.pre

[mmagnuski]

This should be no longer problematic. Everything relies on locked telling apart windows from epochs.