This is indeed a current limitation of Builder. It shouldn’t be hard to fix but we haven’t got around to it. (Have discussed it with @jon before but now I look back through my files, I didn’t document the issue properly, so if you can work through this and report back here, it would be very useful for us to get a fix sorted.)
Yes and no. Currently, there should be a simple workaround where you design and create the experiment in Builder but then do a simple edit to the generated .py file. After that, you will need to run that edited .py script from within Coder (as Builder would overwrite your changes each time it runs).
I’m struggling to recall my solution, but I came across this same problem earlier this year when I wanted to create a quick and dirty fMRI paradigm using Builder but found that the timing wasn’t acceptable over the course of the several minutes of the protocol. This was due to it not using non-slip timing, for the reason you’ve identified.
I think the solution was something like this:
Say you have a stimulus duration that you want to be controlled by a variable from your conditions file but also want non-slip timing. Instead of your variable name, insert a distinctive numeric value (like 9.99) in the duration field. When ready to test your experiment, don’t push the green Run button but instead the Compile script button on the toolbar. In the Coder window that opens, do a find and replace for 9.99, and replace all instances of that with your variable name. Save that script with a new name. To run your actual experiment, open that script file rather than your Builder file, and run it from within Coder.
Hey presto, you should have an experiment structured around non-slip timing but that will use variable durations rather than fixed numeric values. You are still responsible for ensuring that your duration values are sensible multiples of the frame rate (e.g. on a 60 Hz display, a stimulus can be displayed for 50 ms or 500 ms but not, say 60 ms or 520 ms).
Let us know if the solution above works and gives you good results. If this is actually what I did, I found the overall duration of the task to be within a couple of milliseconds of the intended duration for a run of 6 min 24 s, whereas without non-slip timing, the total duration drifted by quite a few seconds as the lags accumulated.
You don’t need to look at the compiled script: Builder shows routines in green in the flow panel if they have non-slip timing, and red otherwise.
Lastly, think about whether you actually need non-slip timing. It is often really only necessary for things like fMRI studies, where timing across trials needs to be taken into account as well as timing within trials. You might actually find that non-slip timing may not be necessary, or even desirable, for your particular requirements.
