FIX: Remove EDF stim code

[larsoner]

I'm not sure we can remove all of it because I don't fully understand:

1. Tal chanels
2. BDF format

It looks like BDF might actually have a proper stim channel in the data (see #5160), in which case we probably need to keep the stim_channel argument but only use it for BDF files.

@massich can you take a look at #5160 and the EDF code, see if you get the same sense from it, and discuss with @agramfort what the best plan of action is?

[cbrnr]

BDF doesn't have more proper stim channels than EDF - they are exactly the same. The only difference is that they are called BDF Annotations instead of EDF Annotations (and of course BDF uses 3 bytes instead of 2 to store data).

[larsoner]

Some test file we have has a channel name Status -- this is not a TTL / stim channel? I did not look too closely when trying to get rid of the STIM channel synthesis.

Is it your understanding that none of EDF/BDF/GDF have TTL/stim-like channels, and that all their events are stored in annotation-like form?

I don't know how the TAL channel business works, either -- should these also end up as Annotations in our new way of doing things?

[cbrnr]

Some test file we have has a channel name Status -- this is not a TTL / stim channel? I did not look too closely when trying to get rid of the STIM channel synthesis.

Is it your understanding that none of EDF/BDF/GDF have TTL/stim-like channels, and that all their
events are stored in annotation-like form?

Only EDF/BDF do not support events in annotation-like form - here, a stim-like channel is the only way to store events (I think these channels are often called "Status"). EDF+/BDF+ support events as annotations in a TAL channel (these channels are often called EDF Annotations or BDF Annotations), and GDF supports an event table at the end of the file. However, all formats can be used to also store stim-like channels. Therefore, I think it might be good to keep the stim_channel argument around.

I don't know how the TAL channel business works, either -- should these also end up as Annotations in our new way of doing things?

Yes. These are events as annotations, and I think they already end up as annotations in MNE.

[larsoner]

@cbrnr we are trying to have a STIM channel if and only if the file we are reading in itself has data stored as an event channel (like they do in Neuromag, but don't in formats like BrainVision). So you're saying that for EDF(+)/BDF(+)/GDF we still need stim_channel='auto' as default because they can all have stim channels? But we should be okay to never synthesize a stim channel based on any annotation/tal channels?

In that case, the arg stays, but our reading logic should change. And we might need to change our 0.17 deprecation message in 0.17.1.

[massich]

#5741

[cbrnr]

I don't quite get what you want to do. I think the idea is to never synthesize a stim channel, but instead create annotations. This is a good idea, but I don't think this should depend on how events are actually stored in the file. Some file formats like EDF/BDF can only store events in a standard continuous channel, whereas other formats like EDF+/BDF+ or GDF/BrainVision use a special channel for annotations or store discrete events in a table or similar structure, respectively. Especially in the case of EDF/BDF, the user needs to be able to inform the reader if an event channel is present (although most of the times, we can infer this from the channel name, which I think is usually "Status").

However, what if I have data stored in a format which does support discrete events, but I actually recorded an analog event channel and I want to use this channel for my events? I need to be able to tell the reader that I want my annotations to come from this particular channel. Is this still possible with what you are planning to do?

[massich]

wait. what? Can we have a an analog event channel on the data? Do we have such data in the testsuit?

[cbrnr]

This is at least my understanding of the formats. I mean, you can have an analog stim channel in all formats - if you record and store this as a regular channel. But normal EDF/BDF files do not support events or TAL channels, so I am pretty sure that any stim channel needs to be stored as a regular continuous data channel. I think by convention such a channel is usually called "Status", which is how readers could treat such channels differently than normal channels.

I think mne/io/edf/tests/data/test.bdf is a file with a continuous status channel (called "Status"). However, I'm not even sure if this file is EDF/BDF compliant, because pyedflib complains that "the file is not EDF(+) or BDF(+) compliant (Number of Datarecords)".

[cbrnr]

Currently, stim_chan='auto' means that we take the last channel as the stim channel.

[massich]

yes

[cbrnr]

So I guess what I'm saying is that we still need to parse analog channels that are used for stim information for standard EDF/BDF - these formats do not store events. And we can't automatically assume how the contents of these channels look like, because this is not standardized at all.

[cbrnr]

But: we don't need to synthesize stim channels anymore. If there are discrete events, we can automatically generate annotations. If there are explicit analog event channels in the data, then this remains in the data and can be parsed by the user with mne.find_events.