More user control over the prepare/run strategy

[mwshinn]

To reproduce:

1. Create a simple experiment with a simple series of timed trials. Set each one to take 700 ms or so.
2. Add many trials to the loop (say 100 or so)
3. Run the experiment and find the average time spent on each trial. It should be approximately equal to what you specified in step 1.
4. Add six or seven slides, text inputs, etc. Change all their "Run if..." values to something impossible (say, "[correct] = 10")
5. Repeat step 3. This should add about 40-50 ms to the trial. (In one extreme case with 16 conditional display expressions, the trials were slowed down by about 100 ms.)

In comparison with python scripts (which seem to run relatively quickly), this is very time consuming. Granted, this isn't the most precise measurement form in the world, but it gives a good rough estimate of how slow this is. I'm running GNU/Linux, and top indicates very low cpu usage.

Not only is this a problem on its own, but I am currently building an experiment that requires the user to be able to press a particular key at any point in the experiment, and to have that key press be recorded. Through some hacks I have made this work with OpenSesame, but it seems there is no way to record that key press if it is pressed during this latency period.

[smathot]

Hi Max,

Thanks again for your feedback!

I suspect that the delay you're seeing is not related to the conditional statements per se, but to the prepare-run strategy that is used by OpenSesame.

Essentially, every sequence is prepared (the prepare phase) before it is executed (the run phase). The reason behind this is to perform all time consuming tasks in the prepare phase, so that timing during the run phase can be properly controlled. For example, all sketchpads that are part of a sequence are prepared before the sequence is executed. However, a loop is not prepared in its entirety. The reasoning is that the time critical part (i.e., a trial) of the experiment will typically be a sequence, and that some variable delay between sequences is acceptable.

Conditional statements are first translated into Python and then byte compiled. So running a conditional statement is very efficient, but it takes some time to prepare them. This is why you're seeing a delay. The same thing would happen if you use very complex sketchpads, which also take some time to prepare.

So the bottom line is that you can rely on the timing within a sequence, but not on the timing between sequences (ie. in a loop). This is usually fine (which is why I designed it like this in the first place), but the point has been raised before that this should be made more flexible. Specifically, there could be a checkbox which allows you to prepare a complete loop in the same way that a sequence is prepared. I'm planning to implement this, probably for 0.26, but for now the prepare-run structure is fixed.

Does this make sense? Do you agree that this is what happening? There are ways around this, though. If you need any help, don't hesitate to post your questions on the forum: http://forum.cogsci.nl/

Kindest regards, Sebastiaan