Durations listed on the bar at the bottom of the visual view and durations listed on the table view of each condition are different, and I don't think either is calculated exactly the way we want.
Because we need to be able to run other commands, like turning the backlight on and off, while a pattern displays, the experiment execution code does NOT pause for the duration of the pattern display. This means that when you create a condition in your experiment yaml, you must put in a pause for the duration of the pattern display so the code knows to wait for it to finish. For example, a condition could have these commands (paraphrased, not accurate code)
trialParams command with 10s duration
wait for 10s
OR
trialParams command with 10s duration
wait for 3 s
turn on a light
wait for 7 s
turn off a light
Either way, the waits need to add up to the same duration as the trialParams if you want the condition to run the entire pattern display but not have any additional time without the pattern displaying.
The bar at the bottom gets its duration purely from the trialParams command. Any additional waits or commands are not taken into account, and this is correct as long as the wait commands do actually add up to the trialParams duration. But say for example I accidentally put in a wait of 70 seconds instead of 7 in that second example above. That would create a condition that displays a pattern for 10 seconds and then just displays the backlight for another 63 seconds before moving on. It might be helpful to have the duration calculated as the trialParams duration plus any waits in excess of the trialParams duration, so that the user can easily see if the duration of their condition as a whole does not match their trialParams duration.
The table view, on the other hand, adds the trialParams duration and all the wait durations together, so both examples above show a condition duration of 20s in the table view instead of 10, which is definitely not correct.
Durations listed on the bar at the bottom of the visual view and durations listed on the table view of each condition are different, and I don't think either is calculated exactly the way we want.
Because we need to be able to run other commands, like turning the backlight on and off, while a pattern displays, the experiment execution code does NOT pause for the duration of the pattern display. This means that when you create a condition in your experiment yaml, you must put in a pause for the duration of the pattern display so the code knows to wait for it to finish. For example, a condition could have these commands (paraphrased, not accurate code)
trialParams command with 10s duration
wait for 10s
OR
trialParams command with 10s duration
wait for 3 s
turn on a light
wait for 7 s
turn off a light
Either way, the waits need to add up to the same duration as the trialParams if you want the condition to run the entire pattern display but not have any additional time without the pattern displaying.
The bar at the bottom gets its duration purely from the trialParams command. Any additional waits or commands are not taken into account, and this is correct as long as the wait commands do actually add up to the trialParams duration. But say for example I accidentally put in a wait of 70 seconds instead of 7 in that second example above. That would create a condition that displays a pattern for 10 seconds and then just displays the backlight for another 63 seconds before moving on. It might be helpful to have the duration calculated as the trialParams duration plus any waits in excess of the trialParams duration, so that the user can easily see if the duration of their condition as a whole does not match their trialParams duration.
The table view, on the other hand, adds the trialParams duration and all the wait durations together, so both examples above show a condition duration of 20s in the table view instead of 10, which is definitely not correct.