ensure continuous recording

[Remi-Gau]

ensures that the file generated have continuous recording

[julia-pfarr]

What does that mean exactly? I'm sorry, I've always had troubles understanding this. Does that have to do with the timestamps? The samples do have continuous recording (=_recording-_physio.tsv.gz file). The events (=_recording-_physioevents.tsv.gz) does not. So for the events we would have to add extra "empty" rows that the timestamp is continous?

Is that what you mean? (asking because I'm currently working on the code for the _physioevents.tsv.gz file)

[Remi-Gau]

Yes the idea would be to pad physio.tsv.gz with rows of n/a for missing time stamps.

[julia-pfarr]

Ok, yes, I discussed this in our last meeting with Oscar and Martin. So the data (=physio.tsv.gz) should have continuous recording and I still need to modify the edf2bids code that it checks for continuity and if not fill with n/a rows. The events file however (=physioevents.tsv.gz) should not be continuous.

[julia-pfarr]

todo:
add function to check the samples for continuous recordings; if False fill missing rows with continuous timestamps and nans for coordinates/pupil

[Remi-Gau]

OK I need to make sure that we have a test that actually make sure we throw a warning or an error if the output file does not have a continuous timestamp

[julia-pfarr]

But I thought we want to take care of it?

Yes the idea would be to pad physio.tsv.gz with rows of n/a for missing time stamps.

This and the last discussions in the meetings sounded to me as if we check during the conversion process if timestamps are continuous and if not we modify the tsv by adding the rows, no? We can still throw a warning letting the user know that we modified their file in this manner but an error would mean we leave it to the user to take care of it themselves and run our converter again afterwards.