2

I am learning PsychToolBox and referring to this tutorial. http://peterscarfe.com/movingdotgriddemo.html

There is this line :

vbl  = Screen('Flip', window, vbl + (waitframes - 0.5) * ifi); 

which I cannot figure out. Can someone please explain it to me? Especially the vbl + (waitframes - 0.5) * ifi) part. Thanks!

Suever
  • 64,497
  • 14
  • 82
  • 101
TYL
  • 1,577
  • 20
  • 33
  • I don't think that you're going to have a lot of answer if you don't post the code of the function `screen` and if you don't explain what are waitframes and ifi. – obchardon Jun 24 '16 at 14:16

2 Answers2

3

the vbl on the LHS (left hand side) is a variable in which the time that the screen 'flipped' is stored.

The RHS is a command from PTB telling the window to flip - Screen('Flip',window) - the vbl + (waitframes - 0.5)*ifi is an additional parameter in the flip instructions telling the computer to wait for that moment to flip the screen. I.e. Screen('Flip',window,when)

In this case, the screen will flip (waitframes - 0.5)*ifi seconds after the previous flip (the vbl + ...) bit. Because ifi is the interframe interval (the time between successive refreshes of the screen), we could simply say vbl + ifi, which will flip the screen on every refresh, however, we add the (waitframes - 0.5) multiplier in there so that we can specify how many refreshes we should wait before flipping the screen again. I've never really understood the logic of the -0.5 part, so I'll be interested to see whether anyone can answer that bit.

Anyway, after it's flipped the screen, it saves the time the screen flipped, so that the next flip command can use that timestamp as the basis for specifying when that next flip should occur (vbl+(waitframes-0.5)*ifi

Alex
  • 31
  • 1
3

Everything Alex said is correct; I'm just adding an explanation for the -0.5 (I don't have enough reputation to comment on his answer)

To recap: On each loop / frame, you flip the screen buffers and get the time of the flip in the vbl variable. In the next loop, you time the next flip according to the last one, i.e. vbl + [some number of seconds]. Thus your line of code is both using the previous value of vbl in the function call, and setting it to a new value which the function returns. vbl is updated on a rolling basis. vbl is the 'vertical blanking' time, a pretty accurate estimate of when your monitor actually refreshed*, so aligning frames to this is a good idea.

The question is how far ahead from the last vbl to do the next flip. As Alex said, ifi is the time between refreshes, or 1/[your monitor refresh rate in Hz]. Lets ignore waitframes for now and assume you want to flip on every monitor refresh, i.e. waitframes = 1.

Then your line of code simplifies to

vbl  = Screen('Flip', window, vbl + ifi/2);

so we are asking to flip half an ifi before the next refresh. Why not just ask to flip on the next refresh, i.e. vbl + ifi? Because that sum is a floating-point calculation and may contain small rounding errors. Screen('Flip') can only swap the screen buffers on the next monitor refresh, so what happens if the error in that sum slightly overshoots? Then you've just asked for a flip time slightly beyond the monitor refresh you actually wanted, and PTB has to wait almost an entire ifi to actually flip**.

So we ask for a flip time some amount (less than ifi) before the desired monitor refresh - ifi/2 is reasonable. We're really saying "do the next flip ASAP after vbl+ifi/2", knowing both that Screen('Flip') can't actually do it prior to the refresh, and safe in the knowledge that we have ifi/2 leeway to absorb minor inaccuracies in the timing calculation.

The arithmetic of waitframes is left as an exercise for the reader.

*assuming PTB is set up correctly to play nice with your hardware - pay attention to those warning messages!

**Even worse, this might not show up in PTB's errors e.g. the dropped frame count, because PTB has achieved what you asked it: flipped the buffers on the next monitor refresh from your specified time. In that case the only way you'd know your experiment was lagging and presenting mis-timed stimuli would be if you happened to spot it during runtime!

benxyzzy
  • 315
  • 3
  • 13