Millisecond Forums

After thinking about this for a while, here's what I would do (not sure if correct, please use your own judgement).

#1: Compute the difference (s - a).
#2: If the *absolute value* of  the difference abs(s - a) < 30 -- i.e. less than half a rotation -- you are done.
#3: If the absolute value is > 30 AND the difference is negative, compute 60 + (s - a). Done.
#4: If the absolute value is > 30 AND the difference is positive, compute (s - a) - 60. Done.

To illustrate:

<values>
/ s = 0
/ a = 0
</values>

<expressions>
/ diff = (values.s - values.a)
/ diff_abs = abs(values.s - values.a)
/ score = if (expressions.diff_abs < 30) {expressions.diff}
    else if (expressions.diff < 0) (60 + expressions.diff)
    else if (expressions.diff > 0) (expressions.diff - 60)
</expressions>

<surveypage mypage>
/ ontrialend = [values.s = textbox.s_input.response; values.a = textbox.a_input.response]
/ questions = [1=s_input; 2=a_input]
/ branch = [trial.result]
/ showquestionnumbers = false
/ showpagenumbers = false
</surveypage>

<textbox s_input>
/ caption = "Enter value for S (must be between 0 and 59):"
/ mask = positiveintegerorzero
</textbox>

<textbox a_input>
/ caption = "Enter value for A (must be between 0 and 59):"
/ mask = positiveintegerorzero
</textbox>

<trial result>
/ stimulusframes = [1=resulttxt]
/ validresponse = (57)
/ branch = [surveypage.mypage]
</trial>

<text resulttxt>
/ items = ("Inputs: S=<%values.s%> | A=<%values.a%>
Difference=<%expressions.diff%> | Absolute Difference=<%expressions.diff_abs%>
Score=<%expressions.score%>")
/ size = (75%, 50%)
</text>

<block myblock>
/ trials = [1=mypage]
</block>

Hi Dave,

Many thanks - the <expressions> addition resolved the issue perfectly. 

That appears to be the last of the issues I am unable to resolve myself - except one that I've just noticed, which is that occasionally there is a delay at the beginning of <block rotate_p_block> in:

<block rotate_p_block>
/bgstim = (clock1)
/trials = [1 = response_p; 2 = audio_p]
/branch = [block.estimate_block]
</block>

<trial response_p>
/ontrialbegin = [values.responsetrial_starttime = block.rotate_p_block.elapsedtime]
/correctresponse = (57)
/ontrialend = [values.response_time = block.rotate_p_block.elapsedtime]
/ontrialend = [values.clock_number = 1]
/recorddata = false
</trial>

<trial audio_p>
/ontrialbegin = [values.audiotrial_starttime = block.rotate_p_block.elapsedtime]
/ontrialbegin = [trial.audio_p.insertstimulustime(sound.possounds, values.delay = 258)]
/ontrialend = [values.sound_starttime = values.audiotrial_starttime + sound.possounds.stimulusonset]
/ontrialend = [trial.audio_p.resetstimulusframes(0)]
/ontrialend = [values.onset = values.sound_starttime - values.response_time]
/ontrialend = [values.sound = sound.possounds.currentitem]
/ontrialend = [values.score = (mod(values.sound_starttime,2580) - values.responsetrial_starttime)/43]
/ontrialend = [values.valence = "Positive"]
/validresponse = (0)
/trialduration = values.delay + values.keep_rotating_for + 1000
/recorddata = false
</trial>

, for whatever reason, where it only displays a blank screen (I am assuming it is loading stimuli during this), this counts towards the values.responsetrial_starttime. Subsequently, this results in a large number (e.g., in excess of 2000), and can skew values.score.

To provide a concrete example, a delay at the beginning results in:
values.responsetrial_starttime = 2302, values.sound_starttime = 4087. Using the previous stated method of calculating values.score (via (mod(values.sound_starttime,2580) - values.responsetrial_starttime)/43), this results in a values.score of -18.488, which obviously does not pertain to a position on the clock. However, using your previous solution to calculate values.difference (i.e., expressions.score), this still provides relatively accurately scores (i.e. from my estimates of the sound's onset, thus I don't know if this is something I should actually be concerned over). Equally, this appears to only affect the first couple of trials (presumably because the stimuli has been fully loaded as a background stimulus).

Your thoughts would be greatly appreciated.
Many thanks,
Josh

Such delays as you describe are not something I'm seeing on my system. It may be that there is something fishy about your video's encoding, I really don't know.

> Equally, this appears to only affect the first couple of trials (presumably because the stimuli has been fully loaded as a background
> stimulus).

Interesting observation, but -- at least to me -- the theory doesn't quite make sense. It should be testable, though:
Add a <block> to the very start that lasts for a couple of clock rotations (i.e., fully "loads" and runs the video) and does nothing else.
If your theory is correct that should affect the delay (i.e. noticeably reduce it)  in any subsequent "real" trials.

I am also wondering why the issue wasn't there before -- or was it and you just didn't notice? If it wasn't, it's likely caused by something else entirely.

Hi Dave,

This has only been present since today, for some unknown reason - I have shut down other programs in use which has reduced it (albeit not entirely), so perhaps it was simply CPU processing being affected. Your method resolved the issue, however the minor glitch where it takes a small moment to reload the stimuli between <block begin_p> and <block rotate_p_block>:

<block begin_p>
/bgstim = (clock1)
/trials = [1 = begin_p]
/branch = [block.rotate_p_block]
</block>

<trial begin_p>
/timeout = 2580
/recorddata = false
</trial>

<block rotate_p_block>
/bgstim = (clock1)
/trials = [1 = response_p; 2 = audio_p]
/branch = [block.estimate_block]
</block>

However, I feel we'll be circulating back towards our previous discussions, so I feel I'll limit the strain on CPU usage and eliminate results where values.responsetrial_starttime is in excess of, for example, 1000, so that they do not potential obscure results, given that they only occur rarely.

Many thanks again,
Josh

Hi Dave,

I have one final question - is there a way to check the speed of the clock? I ask this because in some instances the .avi file seems to run more smoothly than the clock within Inquisit, and the speed of the clock is vital in this particular study (i.e., it must reflect one rotation per 2580ms). 

Many thanks,
Josh

> I ask this because in some instances the .avi file seems to run more smoothly than the clock within Inquisit

Sorry, I don't understand this sentence. What does "run more smoothly than the clock within Inquisit" mean? Thanks.

Sorry for any ambiguity - I meant the .avi file played using a video player (i.e., VLC) runs more smoothly than when Inquisit runs the .avi file as a video stimulus.

Thanks,
Josh

Thanks. That's probably a codec problem then. VLC comes with its own set of binary codecs -- it does not use the codecs that are available system-wide, which are the ones other applications -- including Inquisit -- rely on.

Hi Dave,

Thanks for the info. You have been an enormous help through this study-creation - pardon the many questions due to my novice programming skills.

Many thanks again,
Josh

Hi Dave,

The study has run smoothly, however one extension I'd like to add is the use of multiple clocks to achieve multiple starting points of the clock-hand. Essentially, I have created 7 extra videos where the clock starts elsewhere on the clock, and rotates as usual. These are all fine, except I was wondering how to implement these into the script, and obviously ensure that the data recorded is accurate, given that originally it was simply a method of measuring the elapsed time of the trial and corresponding that to a position on the clock.

For example, I have:

<video clock1>
/items = ("libet.avi")
/playthrough = false
/loop = true
/erase = false
/size = (20%, 20%)
</video>

<video clock2>
/items = ("libet7.avi")
/playthrough = false
/loop = true
/erase = false
/size = (20%, 20%)
</video>

<video clock3>
/items = ("libet14.avi")
/playthrough = false
/loop = true
/erase = false
/size = (20%, 20%)
</video>

<video clock4>
/items = ("libet21.avi")
/playthrough = false
/loop = true
/erase = false
/size = (20%, 20%)
</video>

<video clock5>
/items = ("libet28.avi")
/playthrough = false
/loop = true
/erase = false
/size = (20%, 20%)
</video>

<video clock6>
/items = ("libet35.avi")
/playthrough = false
/loop = true
/erase = false
/size = (20%, 20%)
</video>

<video clock7>
/items = ("libet48.avi")
/playthrough = false
/loop = true
/erase = false
/size = (20%, 20%)
</video>

<video clock8>
/items = ("libet54.avi")
/playthrough = false
/loop = true
/erase = false
/size = (20%, 20%)
</video>

The number within the file name represents the time/starting position of the clock-hand (bar the first clock). 

The block thus looks presently like this:

<block rotate_p_block_aa>
/bgstim = (clock1)
/trials = [1 = response_p_aa; 2 = audio_p_aa]
/branch = [block.estimate_block_action_a]
</block>

<trial response_p_aa>
/ontrialbegin = [values.responsetrial_starttime = block.rotate_p_block_aa.elapsedtime]
/correctresponse = (57)
/ontrialend = [values.response_time = block.rotate_p_block_aa.elapsedtime]
/recorddata = false
</trial>

<trial audio_p_aa>
/ontrialbegin = [values.audiotrial_starttime = block.rotate_p_block_aa.elapsedtime]
/ontrialbegin = [trial.audio_p_aa.insertstimulustime(sound.possounds, values.delay = 258)]
/ontrialend = [values.sound_starttime = values.audiotrial_starttime + sound.possounds.stimulusonset]
/ontrialend = [trial.audio_p_aa.resetstimulusframes(0)]
/ontrialend = [values.onset = values.sound_starttime - values.response_time]
/ontrialend = [values.sound = sound.possounds.currentitem]
/ontrialend = [values.score = (mod(values.response_time,2500) - values.responsetrial_starttime)/41.6667]
/ontrialend = [values.valence = "Positive"]
/ontrialend = [values.elapsed_time = block.rotate_p_block_aa.elapsedtime; values.actual_time = values.sound_starttime + values.keep_rotating_for]
/validresponse = (0)
/trialduration = values.delay + values.keep_rotating_for + 1000
/recorddata = false
</trial>

Please let me know if you need anymore information.

Many thanks,
Josh