@oliche @samupicard

also, from a design-perspective - does it make sense to do this in the state-machine at all?

I don't know about the design question, but the camera-dependency definitely needs to be parametrized. A buggy video PC can currently block up the entire task pipeline, and there is no workaround

also, from a design-perspective - does it make sense to do this in the state-machine at all?

I don't believe it does. This should be part of the pre-session hardware preparation and not executed during the first trial. Because the length of the first trial start pulse is undefined and the Bpod out is multiplexed, our extractors have to 'guess' which pulse to assign to the first trial start event:

https://github.com/int-brain-lab/ibllib/blob/526385b3e7b3962cbd910911409cbf03c4e5a17d/ibllib/io/extractors/ephys_fpga.py#L1149-L1160

This is very unreliable as the valve pulse is also variable in length (depends on water volume and calibration). What's more, if the first trial start pulse is missed on the FPGA (e.g. due to the DAQ starting after task starts, int-brain-lab/ibllib#909) then the first valve pulse may be erroneously interpreted as the trial start. All of this could be resolved by leaving the camera trigger out of the state machine altogether. This could be done elsewhere by manually setting Bpod high until the first Port1In event, or maybe with a pre-task state machine.

make sure to use specific version tag when testing