Millisecond Forums

> It may be the last two questions (i hope so). First one, revised BARTY.iqx works well, however, it seems exceeding 2s than
> expect. Specifically, I expected the totoal time is 3mins 16s (1s fixation+10s instruction+15s*12 balloon+5s feedback).

Well, there's other stuff going on that you cannot control. Sometimes Inquisit will have to wait for the start of a display frame in order to start drawing stuff to the screen, etc. This can add up over the course of the entire task and there's nothing you can do about it.

As for the Cued Go/-No Go: Your math is wrong.

<trial cue> lasts 1300 ms plus a variable soa (see list.soa). <trial iti> lasts 700 ms as per values.iti. That alone gives you 2000ms + soa. If the end result is supposed to be approx. 4000ms for each (cue-target-iti) tuple of trials, the /trialduration of <trial target> should be set to 2000 ms - soa. I have no idea where you get the 3300 ms /posttrialpause figure from. It also seems that there's some confusion left regarding the various timing components of a <trial> and how they interrelate. I strongly recommend reading the "How to Control Trial Duration and Inter-Trial Intervals" topic in the documentation, which explains all of that.

Thanks for your help.

Hi, Dave,
    I really confused about the time control. I set a trial's timeout=9000 and / posttrialpause = trial.5losseva_self.timeout-trial.5losseva_self.elapsedtime (see the attachment). If the elapsedtime is 4s, the trial should pause 5s to the next trial. But it terminate 9s latter after my response, e.g. i response at 4s, it terminate at 13s. I know it works by setting trialduration to 9s, but it will make participants fail to confirm their response while they press the corresponding keys. How can it let it terminate at 9s whatever when participants make their responses within that trial?

> I know it works by setting trialduration to 9s

Then please use /trialduration. That's exactly the scenario it is intended for.

> but it will make participants fail to confirm their response while they press the corresponding keys

I'm not sure what that's supposed to mean. It literally makes no difference. With /trialduration specified, the trial goes into a posttrialpause for the remainder of the specified duration.

> How can it let it terminate at 9s whatever when participants make their responses within that trial?

Use /trialduration.

I finally found that the trial duration of CCT_hot within a round was more than 10s. Actually, i want one round terminate exactly at 10s whatever how many times participants press the button within that period (e.g. In round 1, participant made two presses, first press was at 3s, second at 6s, and i want it to terminate at 10s rather than 16s). Present syntax leads 10s timeout to recalculate after each press within one round (please see attchment). Could you help me to resolve it? Thank you.

I finally found that the trial duration of CCT_hotwithin a round was more than 10s after I pressing more than once. Actually, i want one round terminate exactlyat 10s whatever how many times participants pressedwithin per round (e.g. In round 1, participant made two presses, first press was at 3s, secondat 6s, and i want it to terminate at 10s rather than 16s). Present syntax leads10s timeout to recalculate after each press within one round (please seeattchment). Could you help me resolve it? Thank you.

 

You do it in the same way as with the BARTY, which we discussed in this thread.

I add / branch = [if (trial.pickcard.sumlatency==trial.pickcard.timeout) trial.turnover] in <trial pickcard>, but it was not what I intended.

I revised the script as you mentioned in former post (please see the attachment). However, it only works on the first hot round, the rest of hot trials automatically and immediately terminated before i pressing the button.

Just as with the BARTY, you ought to set the timeout variable to 10 seconds at the beginning of each round.

<trial getcondition>
/ ontrialbegin = [values.pickcardtimeout=10000; ]
...
</trial>