More modalities in the Experiments tests

[pollytur]

In #113 we added to def setup_test_experiment tests/create_experiment.py link

Currently this function only sets up experiments with "modality": "sequence" devices, while ideally we also want screen and TimeIntervals modalities

Extending the data generation and tests is a good way to contribute for experanto

[BitForge95]

Hi @pollytur, I can take this one. It's a great follow-up to #113. I'll prioritize this over the remaining test cases (c, d, e) from #76 for now and loop back to those after. Let me know if you'd prefer a different order.

[pollytur]

ok, thanks for the initiative!
I assigned you to it
Please try to be more attentive this time and check a bit more things yourself.
If in the next PR we would have to catch non-needed changes or comments which were unnecessary deleted - i would close instead of catching line by line as it takes much more time to review

[BitForge95]

@pollytur I appreciate the heads-up and the time you spent reviewing the last one. I will make sure to heavily review my own diffs before submitting next time. Thank you once again.

[BitForge95]

@pollytur just wanted to run this by you quickly before I open a PR.
I’m thinking of updating setup_test_experiment so it checks for a modality key in devices_kwargs, and if it’s not there, it just defaults to sequence so nothing breaks.

Then based on that, I’ll call the right function like create_screen_data, create_time_intervals_data, and so on.
I’ll also add a small test in test_experiment.py where I set up a multi-modality experiment, just to make sure everything loads together without issues.

I’ll keep the changes pretty minimal and focused on just this part. Let me know if this sounds good to you

[BitForge95]

@pollytur, as I'm mapping out the wiring for setup_test_experiment, I noticed that create_screen_data and create_time_interval_data currently use hardcoded paths (e.g., SCREEN_ROOT) and don't expose a generate... function that accepts a dynamic device_path like create_sequence_data does.

To make them work inside setup_test_experiment, my plan is to extract their core logic into _generate_screen_data(path) and _generate_time_interval_data(path) so they match the sequence pattern and can save to the dynamic device_0, device_1 folders.

Just wanted to check with you first, are you okay with me refactoring those two files this way, or would you prefer a different approach for handling the paths?