+x

 

Sadek - 10/22/2020

Hello,

This is a two-part question. Is there a way to specify the duration of the trial by number of frames instead of time? All my parameters are based on stimulus frames (e.g. the insertstimulusframe and beginresponseframe), but the only parameter I can't seem to set by frame is the trialduration (or timeout). I suppose one way to do this is to calculate the duration of the trial based on the total number of frames I would like there to be. However, the issue with this is that if I choose to run the experiment using Inquisit Web, the trialduration value would depend on each monitor's refresh rate (sure, only a few ms off). To avoid this, I would prefer to have the trial duration based on the monitor's refresh rate and avoid any timing hiccups between trials. After collecting all the data, I can separate participants based on their monitor's refresh rate and work from there.

Second, there seems to be a weird timing discrepancy (an issue I have noticed in other threads - and partially a reason why I am structuring my experiment by frame instead of time). Below is a simple series of stimuli (adapted from a previous thread - not an experiment, but rather a proof of concept). I have added the clock feature so I can track when the stimuli appear/disappear. At 60 frames between each stimuli (i.e. 1 second), everything shows up as expected with the exception of the final stimuli (the blank [can also be clearscreen]). Any particular reason why it is delayed? My only guess is that something about indicating when the response can be allowed (beginresponseframe = 180) messes with the timing of the stimulus frames. I notice that if i remove the beginresponseframe variable, there is no time lag between the stimuli and everything is executed every second. If I change the beginresponseframe to earlier, things get messier.. Perhaps I am missing some bit of code..? Or using the wrong bit of code..?

Note: these settings below are based on a monitor with a refresh rate of 60Hz. If you have a monitor with a higher refresh rate (e.g. 100Hz), it will require adjustments to when the frame is presented for each stimuli. Which makes me think that perhaps web-based experiments that are time sensitive should incorporate an ifelse statement checking the monitor's refresh rate and adjusting the experiment's parameters accordingly. Just a side thought since we are increasingly incorporating online testing instead of the usual 'one monitor in the lab sort of gig'.

Thank you for your time and help.
____________________________

<clock stopwatch>
/ mode = stopwatch
/ txcolor = white
/ txbgcolor = black
/ format = "s:zzz"
/ position = (50%, 90%)
</clock>

<block myblock>
/ trials = [1-4=example]
</block>

<trial example>
/ontrialbegin = [
    trial.example.insertstimulusframe(text.target, 60);
    trial.example.insertstimulusframe(shape.square_out, 120);
    trial.example.insertstimulusframe(shape.square_in, 180);
    trial.example.insertstimulusframe(shape.blank, 240);
]
/ ontrialend = [trial.example.resetstimulusframes(); ]
/ stimulusframes = [1 = fixation, clock.stopwatch]
/ beginresponseframe = 180
/ validresponse = (57)
</trial>

<text fixation>
/ items = ("+")
</text>
<shape square_out>
/ shape = rectangle
/ color = orangered
/ size = (210px, 210px)
</shape>
<shape square_in>
/ shape = rectangle
/ color = black
/ size = (200px, 200px)
</shape>
<text target>
/ items = ("TARGET")
/ txcolor = red
</text>
<shape blank>
/ shape = rectangle
/ color = white
/ size = (100%, 100%)
</shape>

+x

 

Dave - 10/22/2020

+x

 

Sadek - 10/22/2020

Hello,

This is a two-part question. Is there a way to specify the duration of the trial by number of frames instead of time? All my parameters are based on stimulus frames (e.g. the insertstimulusframe and beginresponseframe), but the only parameter I can't seem to set by frame is the trialduration (or timeout). I suppose one way to do this is to calculate the duration of the trial based on the total number of frames I would like there to be. However, the issue with this is that if I choose to run the experiment using Inquisit Web, the trialduration value would depend on each monitor's refresh rate (sure, only a few ms off). To avoid this, I would prefer to have the trial duration based on the monitor's refresh rate and avoid any timing hiccups between trials. After collecting all the data, I can separate participants based on their monitor's refresh rate and work from there.

Second, there seems to be a weird timing discrepancy (an issue I have noticed in other threads - and partially a reason why I am structuring my experiment by frame instead of time). Below is a simple series of stimuli (adapted from a previous thread - not an experiment, but rather a proof of concept). I have added the clock feature so I can track when the stimuli appear/disappear. At 60 frames between each stimuli (i.e. 1 second), everything shows up as expected with the exception of the final stimuli (the blank [can also be clearscreen]). Any particular reason why it is delayed? My only guess is that something about indicating when the response can be allowed (beginresponseframe = 180) messes with the timing of the stimulus frames. I notice that if i remove the beginresponseframe variable, there is no time lag between the stimuli and everything is executed every second. If I change the beginresponseframe to earlier, things get messier.. Perhaps I am missing some bit of code..? Or using the wrong bit of code..?

Note: these settings below are based on a monitor with a refresh rate of 60Hz. If you have a monitor with a higher refresh rate (e.g. 100Hz), it will require adjustments to when the frame is presented for each stimuli. Which makes me think that perhaps web-based experiments that are time sensitive should incorporate an ifelse statement checking the monitor's refresh rate and adjusting the experiment's parameters accordingly. Just a side thought since we are increasingly incorporating online testing instead of the usual 'one monitor in the lab sort of gig'.

Thank you for your time and help.
____________________________

<clock stopwatch>
/ mode = stopwatch
/ txcolor = white
/ txbgcolor = black
/ format = "s:zzz"
/ position = (50%, 90%)
</clock>

<block myblock>
/ trials = [1-4=example]
</block>

<trial example>
/ontrialbegin = [
    trial.example.insertstimulusframe(text.target, 60);
    trial.example.insertstimulusframe(shape.square_out, 120);
    trial.example.insertstimulusframe(shape.square_in, 180);
    trial.example.insertstimulusframe(shape.blank, 240);
]
/ ontrialend = [trial.example.resetstimulusframes(); ]
/ stimulusframes = [1 = fixation, clock.stopwatch]
/ beginresponseframe = 180
/ validresponse = (57)
</trial>

<text fixation>
/ items = ("+")
</text>
<shape square_out>
/ shape = rectangle
/ color = orangered
/ size = (210px, 210px)
</shape>
<shape square_in>
/ shape = rectangle
/ color = black
/ size = (200px, 200px)
</shape>
<text target>
/ items = ("TARGET")
/ txcolor = red
</text>
<shape blank>
/ shape = rectangle
/ color = white
/ size = (100%, 100%)
</shape>

A system's refresh cycle duration is available via the display.refreshinterval property
https://www.millisecond.com/support/docs/v6/html/language/properties/refreshinterval.htm

so you can do

<trial example>
...
/ trialduration = 300 * display.refreshinterval
</trial>

if you want a trial to last e.g. 300 frames on any given system.

+x

 

Sadek - 10/22/2020

+x

 

Dave - 10/22/2020

+x

 

Sadek - 10/22/2020

Hello,

This is a two-part question. Is there a way to specify the duration of the trial by number of frames instead of time? All my parameters are based on stimulus frames (e.g. the insertstimulusframe and beginresponseframe), but the only parameter I can't seem to set by frame is the trialduration (or timeout). I suppose one way to do this is to calculate the duration of the trial based on the total number of frames I would like there to be. However, the issue with this is that if I choose to run the experiment using Inquisit Web, the trialduration value would depend on each monitor's refresh rate (sure, only a few ms off). To avoid this, I would prefer to have the trial duration based on the monitor's refresh rate and avoid any timing hiccups between trials. After collecting all the data, I can separate participants based on their monitor's refresh rate and work from there.

Second, there seems to be a weird timing discrepancy (an issue I have noticed in other threads - and partially a reason why I am structuring my experiment by frame instead of time). Below is a simple series of stimuli (adapted from a previous thread - not an experiment, but rather a proof of concept). I have added the clock feature so I can track when the stimuli appear/disappear. At 60 frames between each stimuli (i.e. 1 second), everything shows up as expected with the exception of the final stimuli (the blank [can also be clearscreen]). Any particular reason why it is delayed? My only guess is that something about indicating when the response can be allowed (beginresponseframe = 180) messes with the timing of the stimulus frames. I notice that if i remove the beginresponseframe variable, there is no time lag between the stimuli and everything is executed every second. If I change the beginresponseframe to earlier, things get messier.. Perhaps I am missing some bit of code..? Or using the wrong bit of code..?

Note: these settings below are based on a monitor with a refresh rate of 60Hz. If you have a monitor with a higher refresh rate (e.g. 100Hz), it will require adjustments to when the frame is presented for each stimuli. Which makes me think that perhaps web-based experiments that are time sensitive should incorporate an ifelse statement checking the monitor's refresh rate and adjusting the experiment's parameters accordingly. Just a side thought since we are increasingly incorporating online testing instead of the usual 'one monitor in the lab sort of gig'.

Thank you for your time and help.
____________________________

<clock stopwatch>
/ mode = stopwatch
/ txcolor = white
/ txbgcolor = black
/ format = "s:zzz"
/ position = (50%, 90%)
</clock>

<block myblock>
/ trials = [1-4=example]
</block>

<trial example>
/ontrialbegin = [
    trial.example.insertstimulusframe(text.target, 60);
    trial.example.insertstimulusframe(shape.square_out, 120);
    trial.example.insertstimulusframe(shape.square_in, 180);
    trial.example.insertstimulusframe(shape.blank, 240);
]
/ ontrialend = [trial.example.resetstimulusframes(); ]
/ stimulusframes = [1 = fixation, clock.stopwatch]
/ beginresponseframe = 180
/ validresponse = (57)
</trial>

<text fixation>
/ items = ("+")
</text>
<shape square_out>
/ shape = rectangle
/ color = orangered
/ size = (210px, 210px)
</shape>
<shape square_in>
/ shape = rectangle
/ color = black
/ size = (200px, 200px)
</shape>
<text target>
/ items = ("TARGET")
/ txcolor = red
</text>
<shape blank>
/ shape = rectangle
/ color = white
/ size = (100%, 100%)
</shape>

A system's refresh cycle duration is available via the display.refreshinterval property
https://www.millisecond.com/support/docs/v6/html/language/properties/refreshinterval.htm

so you can do

<trial example>
...
/ trialduration = 300 * display.refreshinterval
</trial>

if you want a trial to last e.g. 300 frames on any given system.

Hi Dave,
Thanks for your speedy response. Works great!
Any advice on the timing aspect of the experiment that I was having problems with? The timing of the last stimulus shows up later than it should (as per the clock's reading).
Much appreciated.

+x

 

Dave - 10/22/2020

+x

 

Sadek - 10/22/2020

+x

 

Dave - 10/22/2020

+x

 

Sadek - 10/22/2020

Hello,

This is a two-part question. Is there a way to specify the duration of the trial by number of frames instead of time? All my parameters are based on stimulus frames (e.g. the insertstimulusframe and beginresponseframe), but the only parameter I can't seem to set by frame is the trialduration (or timeout). I suppose one way to do this is to calculate the duration of the trial based on the total number of frames I would like there to be. However, the issue with this is that if I choose to run the experiment using Inquisit Web, the trialduration value would depend on each monitor's refresh rate (sure, only a few ms off). To avoid this, I would prefer to have the trial duration based on the monitor's refresh rate and avoid any timing hiccups between trials. After collecting all the data, I can separate participants based on their monitor's refresh rate and work from there.

Second, there seems to be a weird timing discrepancy (an issue I have noticed in other threads - and partially a reason why I am structuring my experiment by frame instead of time). Below is a simple series of stimuli (adapted from a previous thread - not an experiment, but rather a proof of concept). I have added the clock feature so I can track when the stimuli appear/disappear. At 60 frames between each stimuli (i.e. 1 second), everything shows up as expected with the exception of the final stimuli (the blank [can also be clearscreen]). Any particular reason why it is delayed? My only guess is that something about indicating when the response can be allowed (beginresponseframe = 180) messes with the timing of the stimulus frames. I notice that if i remove the beginresponseframe variable, there is no time lag between the stimuli and everything is executed every second. If I change the beginresponseframe to earlier, things get messier.. Perhaps I am missing some bit of code..? Or using the wrong bit of code..?

Note: these settings below are based on a monitor with a refresh rate of 60Hz. If you have a monitor with a higher refresh rate (e.g. 100Hz), it will require adjustments to when the frame is presented for each stimuli. Which makes me think that perhaps web-based experiments that are time sensitive should incorporate an ifelse statement checking the monitor's refresh rate and adjusting the experiment's parameters accordingly. Just a side thought since we are increasingly incorporating online testing instead of the usual 'one monitor in the lab sort of gig'.

Thank you for your time and help.
____________________________

<clock stopwatch>
/ mode = stopwatch
/ txcolor = white
/ txbgcolor = black
/ format = "s:zzz"
/ position = (50%, 90%)
</clock>

<block myblock>
/ trials = [1-4=example]
</block>

<trial example>
/ontrialbegin = [
    trial.example.insertstimulusframe(text.target, 60);
    trial.example.insertstimulusframe(shape.square_out, 120);
    trial.example.insertstimulusframe(shape.square_in, 180);
    trial.example.insertstimulusframe(shape.blank, 240);
]
/ ontrialend = [trial.example.resetstimulusframes(); ]
/ stimulusframes = [1 = fixation, clock.stopwatch]
/ beginresponseframe = 180
/ validresponse = (57)
</trial>

<text fixation>
/ items = ("+")
</text>
<shape square_out>
/ shape = rectangle
/ color = orangered
/ size = (210px, 210px)
</shape>
<shape square_in>
/ shape = rectangle
/ color = black
/ size = (200px, 200px)
</shape>
<text target>
/ items = ("TARGET")
/ txcolor = red
</text>
<shape blank>
/ shape = rectangle
/ color = white
/ size = (100%, 100%)
</shape>

A system's refresh cycle duration is available via the display.refreshinterval property
https://www.millisecond.com/support/docs/v6/html/language/properties/refreshinterval.htm

so you can do

<trial example>
...
/ trialduration = 300 * display.refreshinterval
</trial>

if you want a trial to last e.g. 300 frames on any given system.

Hi Dave,
Thanks for your speedy response. Works great!
Any advice on the timing aspect of the experiment that I was having problems with? The timing of the last stimulus shows up later than it should (as per the clock's reading).
Much appreciated.

I don't seem to be able to reproduce this in this case. The system I'm using is running at 50Hz (so 20ms refresh cycle duration), i.e. the timings for

/ontrialbegin = [
  trial.example.insertstimulusframe(text.target, 60);
  trial.example.insertstimulusframe(shape.square_out, 120);
  trial.example.insertstimulusframe(shape.square_in, 180);
  trial.example.insertstimulusframe(shape.blank, 240);
]

would be
~1200 (target)
~2400 (square_out)
~3600 (square_in)
~4800 (blank)

These are the onsets running with /beginresponseframe = 180



and these are the onsets running without



i.e. I'm not seeing any difference in the timing for the last stimulus.

This isn't only the case for the logged onsets, but also comports with the on-screen clock reading, i.e. for the the blank occurs at ~4.8 seconds on the clock in either scenario.

The same is true if I go for 1-second intervals on my system, i.e.

<trial example>
/ ontrialbegin = [trial.example.resetstimulusframes(); ]
/ontrialbegin = [
  trial.example.insertstimulusframe(text.target, 50);
  trial.example.insertstimulusframe(shape.square_out, 100);
  trial.example.insertstimulusframe(shape.square_in, 150);
  trial.example.insertstimulusframe(shape.blank, 200);
]
/ stimulusframes = [1 = fixation, clock.stopwatch]
/ beginresponseframe = 150
/ validresponse = (57)
</trial>



when running with /beginresponseframe = 150, and



when running without /beginresponseframe specified. As before, the logged onsets in both cases coincide with the on-screen clock readings, i.e. stimuli come at a 1-2-3-4 cadence, with no noticeable delay or difference for the blank in either version.

+x

 

Dave - 10/22/2020

+x

 

Dave - 10/22/2020

+x

 

Sadek - 10/22/2020

+x

 

Dave - 10/22/2020

+x

 

Sadek - 10/22/2020

Hello,

This is a two-part question. Is there a way to specify the duration of the trial by number of frames instead of time? All my parameters are based on stimulus frames (e.g. the insertstimulusframe and beginresponseframe), but the only parameter I can't seem to set by frame is the trialduration (or timeout). I suppose one way to do this is to calculate the duration of the trial based on the total number of frames I would like there to be. However, the issue with this is that if I choose to run the experiment using Inquisit Web, the trialduration value would depend on each monitor's refresh rate (sure, only a few ms off). To avoid this, I would prefer to have the trial duration based on the monitor's refresh rate and avoid any timing hiccups between trials. After collecting all the data, I can separate participants based on their monitor's refresh rate and work from there.

Second, there seems to be a weird timing discrepancy (an issue I have noticed in other threads - and partially a reason why I am structuring my experiment by frame instead of time). Below is a simple series of stimuli (adapted from a previous thread - not an experiment, but rather a proof of concept). I have added the clock feature so I can track when the stimuli appear/disappear. At 60 frames between each stimuli (i.e. 1 second), everything shows up as expected with the exception of the final stimuli (the blank [can also be clearscreen]). Any particular reason why it is delayed? My only guess is that something about indicating when the response can be allowed (beginresponseframe = 180) messes with the timing of the stimulus frames. I notice that if i remove the beginresponseframe variable, there is no time lag between the stimuli and everything is executed every second. If I change the beginresponseframe to earlier, things get messier.. Perhaps I am missing some bit of code..? Or using the wrong bit of code..?

Note: these settings below are based on a monitor with a refresh rate of 60Hz. If you have a monitor with a higher refresh rate (e.g. 100Hz), it will require adjustments to when the frame is presented for each stimuli. Which makes me think that perhaps web-based experiments that are time sensitive should incorporate an ifelse statement checking the monitor's refresh rate and adjusting the experiment's parameters accordingly. Just a side thought since we are increasingly incorporating online testing instead of the usual 'one monitor in the lab sort of gig'.

Thank you for your time and help.
____________________________

<clock stopwatch>
/ mode = stopwatch
/ txcolor = white
/ txbgcolor = black
/ format = "s:zzz"
/ position = (50%, 90%)
</clock>

<block myblock>
/ trials = [1-4=example]
</block>

<trial example>
/ontrialbegin = [
    trial.example.insertstimulusframe(text.target, 60);
    trial.example.insertstimulusframe(shape.square_out, 120);
    trial.example.insertstimulusframe(shape.square_in, 180);
    trial.example.insertstimulusframe(shape.blank, 240);
]
/ ontrialend = [trial.example.resetstimulusframes(); ]
/ stimulusframes = [1 = fixation, clock.stopwatch]
/ beginresponseframe = 180
/ validresponse = (57)
</trial>

<text fixation>
/ items = ("+")
</text>
<shape square_out>
/ shape = rectangle
/ color = orangered
/ size = (210px, 210px)
</shape>
<shape square_in>
/ shape = rectangle
/ color = black
/ size = (200px, 200px)
</shape>
<text target>
/ items = ("TARGET")
/ txcolor = red
</text>
<shape blank>
/ shape = rectangle
/ color = white
/ size = (100%, 100%)
</shape>

A system's refresh cycle duration is available via the display.refreshinterval property
https://www.millisecond.com/support/docs/v6/html/language/properties/refreshinterval.htm

so you can do

<trial example>
...
/ trialduration = 300 * display.refreshinterval
</trial>

if you want a trial to last e.g. 300 frames on any given system.

Hi Dave,
Thanks for your speedy response. Works great!
Any advice on the timing aspect of the experiment that I was having problems with? The timing of the last stimulus shows up later than it should (as per the clock's reading).
Much appreciated.

I don't seem to be able to reproduce this in this case. The system I'm using is running at 50Hz (so 20ms refresh cycle duration), i.e. the timings for

/ontrialbegin = [
  trial.example.insertstimulusframe(text.target, 60);
  trial.example.insertstimulusframe(shape.square_out, 120);
  trial.example.insertstimulusframe(shape.square_in, 180);
  trial.example.insertstimulusframe(shape.blank, 240);
]

would be
~1200 (target)
~2400 (square_out)
~3600 (square_in)
~4800 (blank)

These are the onsets running with /beginresponseframe = 180



and these are the onsets running without



i.e. I'm not seeing any difference in the timing for the last stimulus.

This isn't only the case for the logged onsets, but also comports with the on-screen clock reading, i.e. for the the blank occurs at ~4.8 seconds on the clock in either scenario.

The same is true if I go for 1-second intervals on my system, i.e.

<trial example>
/ ontrialbegin = [trial.example.resetstimulusframes(); ]
/ontrialbegin = [
  trial.example.insertstimulusframe(text.target, 50);
  trial.example.insertstimulusframe(shape.square_out, 100);
  trial.example.insertstimulusframe(shape.square_in, 150);
  trial.example.insertstimulusframe(shape.blank, 200);
]
/ stimulusframes = [1 = fixation, clock.stopwatch]
/ beginresponseframe = 150
/ validresponse = (57)
</trial>



when running with /beginresponseframe = 150, and



when running without /beginresponseframe specified. As before, the logged onsets in both cases coincide with the on-screen clock readings, i.e. stimuli come at a 1-2-3-4 cadence, with no noticeable delay or difference for the blank in either version.

Okay, it's possible that there's a single-frame delay in the version with /beginresponseframe specified, but it's super hard to detect, at least on my system. It would be interesting to see the logged onsets from yours.

<trial example>
/ ontrialbegin = [trial.example.resetstimulusframes(); ]
/ontrialbegin = [
  trial.example.insertstimulusframe(text.target, 50);
  trial.example.insertstimulusframe(shape.square_out, 100);
  trial.example.insertstimulusframe(shape.square_in, 150);
  trial.example.insertstimulusframe(shape.blank, 199);
]
/ stimulusframes = [1 = fixation, clock.stopwatch]
/ beginresponseframe = 150
/ validresponse = (57)
</trial>

Onsets when compensating for a single-frame delay are a wee bit closer in the /beginresponseframe specified scenario.

+x

 

Sadek - 10/22/2020

+x

 

Dave - 10/22/2020

+x

 

Dave - 10/22/2020

+x

 

Sadek - 10/22/2020

+x

 

Dave - 10/22/2020

+x

 

Sadek - 10/22/2020

Hello,

This is a two-part question. Is there a way to specify the duration of the trial by number of frames instead of time? All my parameters are based on stimulus frames (e.g. the insertstimulusframe and beginresponseframe), but the only parameter I can't seem to set by frame is the trialduration (or timeout). I suppose one way to do this is to calculate the duration of the trial based on the total number of frames I would like there to be. However, the issue with this is that if I choose to run the experiment using Inquisit Web, the trialduration value would depend on each monitor's refresh rate (sure, only a few ms off). To avoid this, I would prefer to have the trial duration based on the monitor's refresh rate and avoid any timing hiccups between trials. After collecting all the data, I can separate participants based on their monitor's refresh rate and work from there.

Second, there seems to be a weird timing discrepancy (an issue I have noticed in other threads - and partially a reason why I am structuring my experiment by frame instead of time). Below is a simple series of stimuli (adapted from a previous thread - not an experiment, but rather a proof of concept). I have added the clock feature so I can track when the stimuli appear/disappear. At 60 frames between each stimuli (i.e. 1 second), everything shows up as expected with the exception of the final stimuli (the blank [can also be clearscreen]). Any particular reason why it is delayed? My only guess is that something about indicating when the response can be allowed (beginresponseframe = 180) messes with the timing of the stimulus frames. I notice that if i remove the beginresponseframe variable, there is no time lag between the stimuli and everything is executed every second. If I change the beginresponseframe to earlier, things get messier.. Perhaps I am missing some bit of code..? Or using the wrong bit of code..?

Note: these settings below are based on a monitor with a refresh rate of 60Hz. If you have a monitor with a higher refresh rate (e.g. 100Hz), it will require adjustments to when the frame is presented for each stimuli. Which makes me think that perhaps web-based experiments that are time sensitive should incorporate an ifelse statement checking the monitor's refresh rate and adjusting the experiment's parameters accordingly. Just a side thought since we are increasingly incorporating online testing instead of the usual 'one monitor in the lab sort of gig'.

Thank you for your time and help.
____________________________

<clock stopwatch>
/ mode = stopwatch
/ txcolor = white
/ txbgcolor = black
/ format = "s:zzz"
/ position = (50%, 90%)
</clock>

<block myblock>
/ trials = [1-4=example]
</block>

<trial example>
/ontrialbegin = [
    trial.example.insertstimulusframe(text.target, 60);
    trial.example.insertstimulusframe(shape.square_out, 120);
    trial.example.insertstimulusframe(shape.square_in, 180);
    trial.example.insertstimulusframe(shape.blank, 240);
]
/ ontrialend = [trial.example.resetstimulusframes(); ]
/ stimulusframes = [1 = fixation, clock.stopwatch]
/ beginresponseframe = 180
/ validresponse = (57)
</trial>

<text fixation>
/ items = ("+")
</text>
<shape square_out>
/ shape = rectangle
/ color = orangered
/ size = (210px, 210px)
</shape>
<shape square_in>
/ shape = rectangle
/ color = black
/ size = (200px, 200px)
</shape>
<text target>
/ items = ("TARGET")
/ txcolor = red
</text>
<shape blank>
/ shape = rectangle
/ color = white
/ size = (100%, 100%)
</shape>

A system's refresh cycle duration is available via the display.refreshinterval property
https://www.millisecond.com/support/docs/v6/html/language/properties/refreshinterval.htm

so you can do

<trial example>
...
/ trialduration = 300 * display.refreshinterval
</trial>

if you want a trial to last e.g. 300 frames on any given system.

Hi Dave,
Thanks for your speedy response. Works great!
Any advice on the timing aspect of the experiment that I was having problems with? The timing of the last stimulus shows up later than it should (as per the clock's reading).
Much appreciated.

I don't seem to be able to reproduce this in this case. The system I'm using is running at 50Hz (so 20ms refresh cycle duration), i.e. the timings for

/ontrialbegin = [
  trial.example.insertstimulusframe(text.target, 60);
  trial.example.insertstimulusframe(shape.square_out, 120);
  trial.example.insertstimulusframe(shape.square_in, 180);
  trial.example.insertstimulusframe(shape.blank, 240);
]

would be
~1200 (target)
~2400 (square_out)
~3600 (square_in)
~4800 (blank)

These are the onsets running with /beginresponseframe = 180



and these are the onsets running without



i.e. I'm not seeing any difference in the timing for the last stimulus.

This isn't only the case for the logged onsets, but also comports with the on-screen clock reading, i.e. for the the blank occurs at ~4.8 seconds on the clock in either scenario.

The same is true if I go for 1-second intervals on my system, i.e.

<trial example>
/ ontrialbegin = [trial.example.resetstimulusframes(); ]
/ontrialbegin = [
  trial.example.insertstimulusframe(text.target, 50);
  trial.example.insertstimulusframe(shape.square_out, 100);
  trial.example.insertstimulusframe(shape.square_in, 150);
  trial.example.insertstimulusframe(shape.blank, 200);
]
/ stimulusframes = [1 = fixation, clock.stopwatch]
/ beginresponseframe = 150
/ validresponse = (57)
</trial>



when running with /beginresponseframe = 150, and



when running without /beginresponseframe specified. As before, the logged onsets in both cases coincide with the on-screen clock readings, i.e. stimuli come at a 1-2-3-4 cadence, with no noticeable delay or difference for the blank in either version.

Okay, it's possible that there's a single-frame delay in the version with /beginresponseframe specified, but it's super hard to detect, at least on my system. It would be interesting to see the logged onsets from yours.

<trial example>
/ ontrialbegin = [trial.example.resetstimulusframes(); ]
/ontrialbegin = [
  trial.example.insertstimulusframe(text.target, 50);
  trial.example.insertstimulusframe(shape.square_out, 100);
  trial.example.insertstimulusframe(shape.square_in, 150);
  trial.example.insertstimulusframe(shape.blank, 199);
]
/ stimulusframes = [1 = fixation, clock.stopwatch]
/ beginresponseframe = 150
/ validresponse = (57)
</trial>

Onsets when compensating for a single-frame delay are a wee bit closer in the /beginresponseframe specified scenario.

Interesting that these are the timing values that output. I don't know if it is perhaps my system or my eyes playing tricks on me, but when I don't include the beginresponseframe, it feels as though there is no time lag observed from stimulus to stimulus (specifically the disappearance of the square) and it is a seamless second by second transition. When it is included, it really feels like a ~500ms delay. I'm curious about what logged onsets are seen on my end. You'll have to forgive me, but how do I check those?

+x

 

Dave - 10/22/2020

+x

 

Sadek - 10/22/2020

+x

 

Dave - 10/22/2020

+x

 

Dave - 10/22/2020

+x

 

Sadek - 10/22/2020

+x

 

Dave - 10/22/2020

+x

 

Sadek - 10/22/2020

Hello,

This is a two-part question. Is there a way to specify the duration of the trial by number of frames instead of time? All my parameters are based on stimulus frames (e.g. the insertstimulusframe and beginresponseframe), but the only parameter I can't seem to set by frame is the trialduration (or timeout). I suppose one way to do this is to calculate the duration of the trial based on the total number of frames I would like there to be. However, the issue with this is that if I choose to run the experiment using Inquisit Web, the trialduration value would depend on each monitor's refresh rate (sure, only a few ms off). To avoid this, I would prefer to have the trial duration based on the monitor's refresh rate and avoid any timing hiccups between trials. After collecting all the data, I can separate participants based on their monitor's refresh rate and work from there.

Second, there seems to be a weird timing discrepancy (an issue I have noticed in other threads - and partially a reason why I am structuring my experiment by frame instead of time). Below is a simple series of stimuli (adapted from a previous thread - not an experiment, but rather a proof of concept). I have added the clock feature so I can track when the stimuli appear/disappear. At 60 frames between each stimuli (i.e. 1 second), everything shows up as expected with the exception of the final stimuli (the blank [can also be clearscreen]). Any particular reason why it is delayed? My only guess is that something about indicating when the response can be allowed (beginresponseframe = 180) messes with the timing of the stimulus frames. I notice that if i remove the beginresponseframe variable, there is no time lag between the stimuli and everything is executed every second. If I change the beginresponseframe to earlier, things get messier.. Perhaps I am missing some bit of code..? Or using the wrong bit of code..?

Note: these settings below are based on a monitor with a refresh rate of 60Hz. If you have a monitor with a higher refresh rate (e.g. 100Hz), it will require adjustments to when the frame is presented for each stimuli. Which makes me think that perhaps web-based experiments that are time sensitive should incorporate an ifelse statement checking the monitor's refresh rate and adjusting the experiment's parameters accordingly. Just a side thought since we are increasingly incorporating online testing instead of the usual 'one monitor in the lab sort of gig'.

Thank you for your time and help.
____________________________

<clock stopwatch>
/ mode = stopwatch
/ txcolor = white
/ txbgcolor = black
/ format = "s:zzz"
/ position = (50%, 90%)
</clock>

<block myblock>
/ trials = [1-4=example]
</block>

<trial example>
/ontrialbegin = [
    trial.example.insertstimulusframe(text.target, 60);
    trial.example.insertstimulusframe(shape.square_out, 120);
    trial.example.insertstimulusframe(shape.square_in, 180);
    trial.example.insertstimulusframe(shape.blank, 240);
]
/ ontrialend = [trial.example.resetstimulusframes(); ]
/ stimulusframes = [1 = fixation, clock.stopwatch]
/ beginresponseframe = 180
/ validresponse = (57)
</trial>

<text fixation>
/ items = ("+")
</text>
<shape square_out>
/ shape = rectangle
/ color = orangered
/ size = (210px, 210px)
</shape>
<shape square_in>
/ shape = rectangle
/ color = black
/ size = (200px, 200px)
</shape>
<text target>
/ items = ("TARGET")
/ txcolor = red
</text>
<shape blank>
/ shape = rectangle
/ color = white
/ size = (100%, 100%)
</shape>

A system's refresh cycle duration is available via the display.refreshinterval property
https://www.millisecond.com/support/docs/v6/html/language/properties/refreshinterval.htm

so you can do

<trial example>
...
/ trialduration = 300 * display.refreshinterval
</trial>

if you want a trial to last e.g. 300 frames on any given system.

Hi Dave,
Thanks for your speedy response. Works great!
Any advice on the timing aspect of the experiment that I was having problems with? The timing of the last stimulus shows up later than it should (as per the clock's reading).
Much appreciated.

I don't seem to be able to reproduce this in this case. The system I'm using is running at 50Hz (so 20ms refresh cycle duration), i.e. the timings for

/ontrialbegin = [
  trial.example.insertstimulusframe(text.target, 60);
  trial.example.insertstimulusframe(shape.square_out, 120);
  trial.example.insertstimulusframe(shape.square_in, 180);
  trial.example.insertstimulusframe(shape.blank, 240);
]

would be
~1200 (target)
~2400 (square_out)
~3600 (square_in)
~4800 (blank)

These are the onsets running with /beginresponseframe = 180



and these are the onsets running without



i.e. I'm not seeing any difference in the timing for the last stimulus.

This isn't only the case for the logged onsets, but also comports with the on-screen clock reading, i.e. for the the blank occurs at ~4.8 seconds on the clock in either scenario.

The same is true if I go for 1-second intervals on my system, i.e.

<trial example>
/ ontrialbegin = [trial.example.resetstimulusframes(); ]
/ontrialbegin = [
  trial.example.insertstimulusframe(text.target, 50);
  trial.example.insertstimulusframe(shape.square_out, 100);
  trial.example.insertstimulusframe(shape.square_in, 150);
  trial.example.insertstimulusframe(shape.blank, 200);
]
/ stimulusframes = [1 = fixation, clock.stopwatch]
/ beginresponseframe = 150
/ validresponse = (57)
</trial>



when running with /beginresponseframe = 150, and



when running without /beginresponseframe specified. As before, the logged onsets in both cases coincide with the on-screen clock readings, i.e. stimuli come at a 1-2-3-4 cadence, with no noticeable delay or difference for the blank in either version.

Okay, it's possible that there's a single-frame delay in the version with /beginresponseframe specified, but it's super hard to detect, at least on my system. It would be interesting to see the logged onsets from yours.

<trial example>
/ ontrialbegin = [trial.example.resetstimulusframes(); ]
/ontrialbegin = [
  trial.example.insertstimulusframe(text.target, 50);
  trial.example.insertstimulusframe(shape.square_out, 100);
  trial.example.insertstimulusframe(shape.square_in, 150);
  trial.example.insertstimulusframe(shape.blank, 199);
]
/ stimulusframes = [1 = fixation, clock.stopwatch]
/ beginresponseframe = 150
/ validresponse = (57)
</trial>

Onsets when compensating for a single-frame delay are a wee bit closer in the /beginresponseframe specified scenario.

Interesting that these are the timing values that output. I don't know if it is perhaps my system or my eyes playing tricks on me, but when I don't include the beginresponseframe, it feels as though there is no time lag observed from stimulus to stimulus (specifically the disappearance of the square) and it is a seamless second by second transition. When it is included, it really feels like a ~500ms delay. I'm curious about what logged onsets are seen on my end. You'll have to forgive me, but how do I check those?

Run

<clock stopwatch>
/ mode = stopwatch
/ txcolor = white
/ txbgcolor = black
/ format = "s:zzz"
/ position = (50%, 90%)
</clock>

<block myblock>
/ trials = [1-4=example]
</block>

<trial example>
/ ontrialbegin = [trial.example.resetstimulusframes(); ]
/ontrialbegin = [
  trial.example.insertstimulusframe(text.target, 60);
  trial.example.insertstimulusframe(shape.square_out, 120);
  trial.example.insertstimulusframe(shape.square_in, 180);
  trial.example.insertstimulusframe(shape.blank, 240);
]
/ stimulusframes = [1 = fixation, clock.stopwatch]
/ beginresponseframe = 180
/ validresponse = (57)
</trial>

<data>
/ columns = (trialnum text.target.stimulusonset.1, shape.square_out.stimulusonset.1 shape.square_in.stimulusonset.1 shape.blank.stimulusonset.1)
/ separatefiles = true
</data>


<text fixation>
/ items = ("+")
</text>
<shape square_out>
/ shape = rectangle
/ color = orangered
/ size = (210px, 210px)
</shape>
<shape square_in>
/ shape = rectangle
/ color = black
/ size = (200px, 200px)
</shape>
<text target>
/ items = ("TARGET")
/ txcolor = red
</text>
<shape blank>
/ shape = rectangle
/ color = white
/ size = (100%, 100%)
</shape>

+x

 

Sadek - 10/22/2020

+x

 

Dave - 10/22/2020

+x

 

Sadek - 10/22/2020

+x

 

Dave - 10/22/2020

+x

 

Dave - 10/22/2020

+x

 

Sadek - 10/22/2020

+x

 

Dave - 10/22/2020

+x

 

Sadek - 10/22/2020

Hello,

This is a two-part question. Is there a way to specify the duration of the trial by number of frames instead of time? All my parameters are based on stimulus frames (e.g. the insertstimulusframe and beginresponseframe), but the only parameter I can't seem to set by frame is the trialduration (or timeout). I suppose one way to do this is to calculate the duration of the trial based on the total number of frames I would like there to be. However, the issue with this is that if I choose to run the experiment using Inquisit Web, the trialduration value would depend on each monitor's refresh rate (sure, only a few ms off). To avoid this, I would prefer to have the trial duration based on the monitor's refresh rate and avoid any timing hiccups between trials. After collecting all the data, I can separate participants based on their monitor's refresh rate and work from there.

Second, there seems to be a weird timing discrepancy (an issue I have noticed in other threads - and partially a reason why I am structuring my experiment by frame instead of time). Below is a simple series of stimuli (adapted from a previous thread - not an experiment, but rather a proof of concept). I have added the clock feature so I can track when the stimuli appear/disappear. At 60 frames between each stimuli (i.e. 1 second), everything shows up as expected with the exception of the final stimuli (the blank [can also be clearscreen]). Any particular reason why it is delayed? My only guess is that something about indicating when the response can be allowed (beginresponseframe = 180) messes with the timing of the stimulus frames. I notice that if i remove the beginresponseframe variable, there is no time lag between the stimuli and everything is executed every second. If I change the beginresponseframe to earlier, things get messier.. Perhaps I am missing some bit of code..? Or using the wrong bit of code..?

Note: these settings below are based on a monitor with a refresh rate of 60Hz. If you have a monitor with a higher refresh rate (e.g. 100Hz), it will require adjustments to when the frame is presented for each stimuli. Which makes me think that perhaps web-based experiments that are time sensitive should incorporate an ifelse statement checking the monitor's refresh rate and adjusting the experiment's parameters accordingly. Just a side thought since we are increasingly incorporating online testing instead of the usual 'one monitor in the lab sort of gig'.

Thank you for your time and help.
____________________________

<clock stopwatch>
/ mode = stopwatch
/ txcolor = white
/ txbgcolor = black
/ format = "s:zzz"
/ position = (50%, 90%)
</clock>

<block myblock>
/ trials = [1-4=example]
</block>

<trial example>
/ontrialbegin = [
    trial.example.insertstimulusframe(text.target, 60);
    trial.example.insertstimulusframe(shape.square_out, 120);
    trial.example.insertstimulusframe(shape.square_in, 180);
    trial.example.insertstimulusframe(shape.blank, 240);
]
/ ontrialend = [trial.example.resetstimulusframes(); ]
/ stimulusframes = [1 = fixation, clock.stopwatch]
/ beginresponseframe = 180
/ validresponse = (57)
</trial>

<text fixation>
/ items = ("+")
</text>
<shape square_out>
/ shape = rectangle
/ color = orangered
/ size = (210px, 210px)
</shape>
<shape square_in>
/ shape = rectangle
/ color = black
/ size = (200px, 200px)
</shape>
<text target>
/ items = ("TARGET")
/ txcolor = red
</text>
<shape blank>
/ shape = rectangle
/ color = white
/ size = (100%, 100%)
</shape>

A system's refresh cycle duration is available via the display.refreshinterval property
https://www.millisecond.com/support/docs/v6/html/language/properties/refreshinterval.htm

so you can do

<trial example>
...
/ trialduration = 300 * display.refreshinterval
</trial>

if you want a trial to last e.g. 300 frames on any given system.

Hi Dave,
Thanks for your speedy response. Works great!
Any advice on the timing aspect of the experiment that I was having problems with? The timing of the last stimulus shows up later than it should (as per the clock's reading).
Much appreciated.

I don't seem to be able to reproduce this in this case. The system I'm using is running at 50Hz (so 20ms refresh cycle duration), i.e. the timings for

/ontrialbegin = [
  trial.example.insertstimulusframe(text.target, 60);
  trial.example.insertstimulusframe(shape.square_out, 120);
  trial.example.insertstimulusframe(shape.square_in, 180);
  trial.example.insertstimulusframe(shape.blank, 240);
]

would be
~1200 (target)
~2400 (square_out)
~3600 (square_in)
~4800 (blank)

These are the onsets running with /beginresponseframe = 180



and these are the onsets running without



i.e. I'm not seeing any difference in the timing for the last stimulus.

This isn't only the case for the logged onsets, but also comports with the on-screen clock reading, i.e. for the the blank occurs at ~4.8 seconds on the clock in either scenario.

The same is true if I go for 1-second intervals on my system, i.e.

<trial example>
/ ontrialbegin = [trial.example.resetstimulusframes(); ]
/ontrialbegin = [
  trial.example.insertstimulusframe(text.target, 50);
  trial.example.insertstimulusframe(shape.square_out, 100);
  trial.example.insertstimulusframe(shape.square_in, 150);
  trial.example.insertstimulusframe(shape.blank, 200);
]
/ stimulusframes = [1 = fixation, clock.stopwatch]
/ beginresponseframe = 150
/ validresponse = (57)
</trial>



when running with /beginresponseframe = 150, and



when running without /beginresponseframe specified. As before, the logged onsets in both cases coincide with the on-screen clock readings, i.e. stimuli come at a 1-2-3-4 cadence, with no noticeable delay or difference for the blank in either version.

Okay, it's possible that there's a single-frame delay in the version with /beginresponseframe specified, but it's super hard to detect, at least on my system. It would be interesting to see the logged onsets from yours.

<trial example>
/ ontrialbegin = [trial.example.resetstimulusframes(); ]
/ontrialbegin = [
  trial.example.insertstimulusframe(text.target, 50);
  trial.example.insertstimulusframe(shape.square_out, 100);
  trial.example.insertstimulusframe(shape.square_in, 150);
  trial.example.insertstimulusframe(shape.blank, 199);
]
/ stimulusframes = [1 = fixation, clock.stopwatch]
/ beginresponseframe = 150
/ validresponse = (57)
</trial>

Onsets when compensating for a single-frame delay are a wee bit closer in the /beginresponseframe specified scenario.

Interesting that these are the timing values that output. I don't know if it is perhaps my system or my eyes playing tricks on me, but when I don't include the beginresponseframe, it feels as though there is no time lag observed from stimulus to stimulus (specifically the disappearance of the square) and it is a seamless second by second transition. When it is included, it really feels like a ~500ms delay. I'm curious about what logged onsets are seen on my end. You'll have to forgive me, but how do I check those?

Run

<clock stopwatch>
/ mode = stopwatch
/ txcolor = white
/ txbgcolor = black
/ format = "s:zzz"
/ position = (50%, 90%)
</clock>

<block myblock>
/ trials = [1-4=example]
</block>

<trial example>
/ ontrialbegin = [trial.example.resetstimulusframes(); ]
/ontrialbegin = [
  trial.example.insertstimulusframe(text.target, 60);
  trial.example.insertstimulusframe(shape.square_out, 120);
  trial.example.insertstimulusframe(shape.square_in, 180);
  trial.example.insertstimulusframe(shape.blank, 240);
]
/ stimulusframes = [1 = fixation, clock.stopwatch]
/ beginresponseframe = 180
/ validresponse = (57)
</trial>

<data>
/ columns = (trialnum text.target.stimulusonset.1, shape.square_out.stimulusonset.1 shape.square_in.stimulusonset.1 shape.blank.stimulusonset.1)
/ separatefiles = true
</data>


<text fixation>
/ items = ("+")
</text>
<shape square_out>
/ shape = rectangle
/ color = orangered
/ size = (210px, 210px)
</shape>
<shape square_in>
/ shape = rectangle
/ color = black
/ size = (200px, 200px)
</shape>
<text target>
/ items = ("TARGET")
/ txcolor = red
</text>
<shape blank>
/ shape = rectangle
/ color = white
/ size = (100%, 100%)
</shape>

This is the onset of stimulus. There is a ~500ms lag. Just in case the picture doesn't show up, I'm pasting it below:
trialnum    text.target.stimulusonset.1    shape.square_out.stimulusonset.1    shape.square_in.stimulusonset.1    shape.blank.stimulusonset.1
1    986    1984    2984    4508
2    985    1984    2984    4501
3    991    1991    2991    4484
4    992    1991    3000    4508

Also, I am using a Microsoft SurfacePro 4. But i doubt that's the issue.

+x

 

Dave - 10/22/2020

+x

 

Sadek - 10/22/2020

+x

 

Dave - 10/22/2020

+x

 

Sadek - 10/22/2020

+x

 

Dave - 10/22/2020

+x

 

Dave - 10/22/2020

+x

 

Sadek - 10/22/2020

+x

 

Dave - 10/22/2020

+x

 

Sadek - 10/22/2020

Hello,

This is a two-part question. Is there a way to specify the duration of the trial by number of frames instead of time? All my parameters are based on stimulus frames (e.g. the insertstimulusframe and beginresponseframe), but the only parameter I can't seem to set by frame is the trialduration (or timeout). I suppose one way to do this is to calculate the duration of the trial based on the total number of frames I would like there to be. However, the issue with this is that if I choose to run the experiment using Inquisit Web, the trialduration value would depend on each monitor's refresh rate (sure, only a few ms off). To avoid this, I would prefer to have the trial duration based on the monitor's refresh rate and avoid any timing hiccups between trials. After collecting all the data, I can separate participants based on their monitor's refresh rate and work from there.

Second, there seems to be a weird timing discrepancy (an issue I have noticed in other threads - and partially a reason why I am structuring my experiment by frame instead of time). Below is a simple series of stimuli (adapted from a previous thread - not an experiment, but rather a proof of concept). I have added the clock feature so I can track when the stimuli appear/disappear. At 60 frames between each stimuli (i.e. 1 second), everything shows up as expected with the exception of the final stimuli (the blank [can also be clearscreen]). Any particular reason why it is delayed? My only guess is that something about indicating when the response can be allowed (beginresponseframe = 180) messes with the timing of the stimulus frames. I notice that if i remove the beginresponseframe variable, there is no time lag between the stimuli and everything is executed every second. If I change the beginresponseframe to earlier, things get messier.. Perhaps I am missing some bit of code..? Or using the wrong bit of code..?

Note: these settings below are based on a monitor with a refresh rate of 60Hz. If you have a monitor with a higher refresh rate (e.g. 100Hz), it will require adjustments to when the frame is presented for each stimuli. Which makes me think that perhaps web-based experiments that are time sensitive should incorporate an ifelse statement checking the monitor's refresh rate and adjusting the experiment's parameters accordingly. Just a side thought since we are increasingly incorporating online testing instead of the usual 'one monitor in the lab sort of gig'.

Thank you for your time and help.
____________________________

<clock stopwatch>
/ mode = stopwatch
/ txcolor = white
/ txbgcolor = black
/ format = "s:zzz"
/ position = (50%, 90%)
</clock>

<block myblock>
/ trials = [1-4=example]
</block>

<trial example>
/ontrialbegin = [
    trial.example.insertstimulusframe(text.target, 60);
    trial.example.insertstimulusframe(shape.square_out, 120);
    trial.example.insertstimulusframe(shape.square_in, 180);
    trial.example.insertstimulusframe(shape.blank, 240);
]
/ ontrialend = [trial.example.resetstimulusframes(); ]
/ stimulusframes = [1 = fixation, clock.stopwatch]
/ beginresponseframe = 180
/ validresponse = (57)
</trial>

<text fixation>
/ items = ("+")
</text>
<shape square_out>
/ shape = rectangle
/ color = orangered
/ size = (210px, 210px)
</shape>
<shape square_in>
/ shape = rectangle
/ color = black
/ size = (200px, 200px)
</shape>
<text target>
/ items = ("TARGET")
/ txcolor = red
</text>
<shape blank>
/ shape = rectangle
/ color = white
/ size = (100%, 100%)
</shape>

A system's refresh cycle duration is available via the display.refreshinterval property
https://www.millisecond.com/support/docs/v6/html/language/properties/refreshinterval.htm

so you can do

<trial example>
...
/ trialduration = 300 * display.refreshinterval
</trial>

if you want a trial to last e.g. 300 frames on any given system.

Hi Dave,
Thanks for your speedy response. Works great!
Any advice on the timing aspect of the experiment that I was having problems with? The timing of the last stimulus shows up later than it should (as per the clock's reading).
Much appreciated.

I don't seem to be able to reproduce this in this case. The system I'm using is running at 50Hz (so 20ms refresh cycle duration), i.e. the timings for

/ontrialbegin = [
  trial.example.insertstimulusframe(text.target, 60);
  trial.example.insertstimulusframe(shape.square_out, 120);
  trial.example.insertstimulusframe(shape.square_in, 180);
  trial.example.insertstimulusframe(shape.blank, 240);
]

would be
~1200 (target)
~2400 (square_out)
~3600 (square_in)
~4800 (blank)

These are the onsets running with /beginresponseframe = 180



and these are the onsets running without



i.e. I'm not seeing any difference in the timing for the last stimulus.

This isn't only the case for the logged onsets, but also comports with the on-screen clock reading, i.e. for the the blank occurs at ~4.8 seconds on the clock in either scenario.

The same is true if I go for 1-second intervals on my system, i.e.

<trial example>
/ ontrialbegin = [trial.example.resetstimulusframes(); ]
/ontrialbegin = [
  trial.example.insertstimulusframe(text.target, 50);
  trial.example.insertstimulusframe(shape.square_out, 100);
  trial.example.insertstimulusframe(shape.square_in, 150);
  trial.example.insertstimulusframe(shape.blank, 200);
]
/ stimulusframes = [1 = fixation, clock.stopwatch]
/ beginresponseframe = 150
/ validresponse = (57)
</trial>



when running with /beginresponseframe = 150, and



when running without /beginresponseframe specified. As before, the logged onsets in both cases coincide with the on-screen clock readings, i.e. stimuli come at a 1-2-3-4 cadence, with no noticeable delay or difference for the blank in either version.

Okay, it's possible that there's a single-frame delay in the version with /beginresponseframe specified, but it's super hard to detect, at least on my system. It would be interesting to see the logged onsets from yours.

<trial example>
/ ontrialbegin = [trial.example.resetstimulusframes(); ]
/ontrialbegin = [
  trial.example.insertstimulusframe(text.target, 50);
  trial.example.insertstimulusframe(shape.square_out, 100);
  trial.example.insertstimulusframe(shape.square_in, 150);
  trial.example.insertstimulusframe(shape.blank, 199);
]
/ stimulusframes = [1 = fixation, clock.stopwatch]
/ beginresponseframe = 150
/ validresponse = (57)
</trial>

Onsets when compensating for a single-frame delay are a wee bit closer in the /beginresponseframe specified scenario.

Interesting that these are the timing values that output. I don't know if it is perhaps my system or my eyes playing tricks on me, but when I don't include the beginresponseframe, it feels as though there is no time lag observed from stimulus to stimulus (specifically the disappearance of the square) and it is a seamless second by second transition. When it is included, it really feels like a ~500ms delay. I'm curious about what logged onsets are seen on my end. You'll have to forgive me, but how do I check those?

Run

<clock stopwatch>
/ mode = stopwatch
/ txcolor = white
/ txbgcolor = black
/ format = "s:zzz"
/ position = (50%, 90%)
</clock>

<block myblock>
/ trials = [1-4=example]
</block>

<trial example>
/ ontrialbegin = [trial.example.resetstimulusframes(); ]
/ontrialbegin = [
  trial.example.insertstimulusframe(text.target, 60);
  trial.example.insertstimulusframe(shape.square_out, 120);
  trial.example.insertstimulusframe(shape.square_in, 180);
  trial.example.insertstimulusframe(shape.blank, 240);
]
/ stimulusframes = [1 = fixation, clock.stopwatch]
/ beginresponseframe = 180
/ validresponse = (57)
</trial>

<data>
/ columns = (trialnum text.target.stimulusonset.1, shape.square_out.stimulusonset.1 shape.square_in.stimulusonset.1 shape.blank.stimulusonset.1)
/ separatefiles = true
</data>


<text fixation>
/ items = ("+")
</text>
<shape square_out>
/ shape = rectangle
/ color = orangered
/ size = (210px, 210px)
</shape>
<shape square_in>
/ shape = rectangle
/ color = black
/ size = (200px, 200px)
</shape>
<text target>
/ items = ("TARGET")
/ txcolor = red
</text>
<shape blank>
/ shape = rectangle
/ color = white
/ size = (100%, 100%)
</shape>

This is the onset of stimulus. There is a ~500ms lag. Just in case the picture doesn't show up, I'm pasting it below:
trialnum    text.target.stimulusonset.1    shape.square_out.stimulusonset.1    shape.square_in.stimulusonset.1    shape.blank.stimulusonset.1
1    986    1984    2984    4508
2    985    1984    2984    4501
3    991    1991    2991    4484
4    992    1991    3000    4508

Also, I am using a Microsoft SurfacePro 4. But i doubt that's the issue.

Huh, that's really odd. What's the Inquisit version installed (Help -> About...) and do you see the same issue on other systems you have available?

+x

 

Sadek - 10/22/2020

Okay, so I have tested it with two different systems. An old desktop (my neighbor's) and the second SurfacePro I have. Timing is perfect and as it should be on the desktop, but not with the second SurfacePro. So it is an issue with the SurfacePro, and I'm not really sure I can give an explanation for why that is the case. I suppose problem solved, but not for the SurfacePro.