dealing with event values v field

[Kalle-pixel]

@CPernet and myself updated the function to handle the case when event.code field doesn't exist but event.type does. We encountered EEG files with event.type being 'boundary' which raised errors in pop_importmff, the code now handles this case.

[CPernet]

just clarify further, the code expects event.(field) for instance 'code' (defined as input) but occasionally, this field becomes a value in event.type .. we did not quite follow how that happens, and simply wrote a workaround.

[arnodelorme]

The destination is set at import time by using the "typefield" parameter of this function (pop_importmff). What if someone selects a different field for type? Will the function crash? I think it is safer to use "code" all the time.

[CPernet]

code and boundary are names from the native data, so typically we call the function passing code as typefield as you describe but somehow for a few subjects event.(typefield) ie event.code turns into event.type = 'code' hence our workaround. Now I do not know if other people use other fields in the native data, but the default for any trigger/events goes into code (don't ask me how for 2 out of 300 subjects, we have 'boundary' instead)

--> PS: in resting state data, there is no code but the typefield is usually empty, but occasionally is event.type