boubre
commented
5 months ago LGTM. I have some concerns about the compatibility of the task param logging with the coming changes since the new model is quite different, but we will see how it goes when it's time to merge my code.
I agree. The current approach is to log the contents of the complex/nested types as JSON.
Here is the behemoth rework of MOT aiming to resolve many issues. (See https://docs.google.com/presentation/d/1bNXGpQdqgWz-IgGOfJATT5zYnNhfSuKW-RWNk4eQrck/edit#slide=id.g2a76d4f4e02_0_0)
A separate PR for the configs will be made in that repo.
MOT is coded as a set of frame chunks. Each chunk is a series of frames. A frame can be an image frame (e.g., instructions) or a trial frame. A trial can be an example trial, a practice trial, or a test trial. This design was inherited from the previous version of MOT but is hopefully more clear/explicit now.
The task has been split out into three modules: task, frame, and animate. Task controls the overall flow and is what actually inherits from the task class. Frame is responsible for visual presentation to the screen. Animate is the logical model of the movement of circles in a trial frame. In other words, frame should handle flashing circles and actually drawing them to the screen whereas animate handles the logical model of each circle and manages HOW their positions update.
The old code for generating circle paths for a trial has been refactored into animate.StepwiseAnimator. I think it makes sense to keep this around in case we ever want to write a script to generate new trials. Or, at the very least we should preserve it until the PR is squashed and merged before removing it so that it remains in the commit history.
The creation of an update script to update old outcome/result CSV files can be handled as a separate PR.