I've found a possible major problem with trying to fix things this way for the visual stream - I have found at least one example in dataset 4 where the visual frames pause for a whole two seconds, and then carry on. (participant 1, second presentation).
This means most of that repetition is out by a whole 2000ms - i.e. unusable if we use this method. The other three reps I looked at were very stable (exactly the same, continuous drift) - but I don't know how common this 'visual frames pause' issue is. Perhaps we should be checking for this and then rejecting any reps that have this issue?
(the whole reason that I put in triggers every second was to guard against this possibility – but I didn't actually realise it was necessary for some reps)
Depending how many 'pauses' are present, we may have to use the events as an override of some sort.
To deal with this we need to:
[ ] Understand the extent on the problem by looking at the trigger 2s in dataset 4 and 3
[ ] In Pychtoolbox, can we force it to miss frames instead of pausing frames? (i.e future proofing)
[ ] Work out testing and correction strategy for current erroneous data (i.e using the trigger two events)
from #290
To deal with this we need to: