Millisecond Forums

Hi,

To keep things simple, you'd probably have to use expressions for that. I'd do something like this.

(1) Define a variable that holds the phrase to be displayed

<values>
/ phrase = ""
/ wordduration = 1000
</values>

(2) Make every phrase a counter (and include the spaces!), such as

<counter COUNTER_phrase1>
/ items = ("Is", " this", " fair")
/ select = sequence
</counter>

(3) Define a text stimulus to show the phrase

<text TEXT_phrase>
/ items = "<%values.phrase%>"
/ position = (50, 50)
/ hjustify = left
</text>

(4) The trial needs to be a tad more complex

<trial TRIAL_phrase1>
/ ontrialbegin = [values.phrase = concat(values.phrase, counter.COUNTER_phrase1.selectedvalue)]
/ ontrialend = [if(counter.COUNTER_phrase1.selectedindex >= counter.COUNTER_phrase1.itemcount) values.phrase=""]
/ stimulustimes = [0 = TEXT_phrase]
/ trialduration = values.wordduration
/ validresponse = (noresponse, " ")
/ responseinterrupt = immediate
/ timeout = (counter.COUNTER_phrase1.selectedindex >= counter.COUNTER_phrase1.itemcount) * 10000 + values.wordduration
/ branch = [if(counter.COUNTER_phrase1.selectedindex < counter.COUNTER_phrase1.itemcount) TRIAL_phrase1]
</trial>

This should work but you have to define one trial for each sentence. Dave will probably find a leaner solution using string manipulation functions but at the moment, I can't think of any.

Problem is that a subject can speed up presentation by pressing a key
due to "responseiterrupt = immediate". If "validresponse" accepts a
<value> element, you could define a different character (of which the subject is unaware) in the
ontrialbegin statement for every but the last trial.

Bye, Malte.

I've attached a functional script that does what you want. It even prevents the subject to click through the phrases.

HTH, Malte

My ambition was tickled. Attached you find a script that's a bit more complicated but much easier to maintain and enhance. It fulfils all your requirements and only needs as many trials as there are phrase lengths in your set (i.e. sentences from, for example, 2 to 5 words).

Adding phrases with lengths already covered in the script is easy. Just add the phrases as elements to the respective counter.

Making the script cover more phrase lengths looks intriguing but is in fact a quite mechanical process. You just have to carefully follow these steps:

(1) Define a new counter for your desired phrase length, say "COUNTER_phrases_length7"

(2) Expand the item "ITEM_canvas" by as many dummy entries as the maximum number of words in any phrase.

(3) Create as many "TEXT_phraseX" stimuli as the maximum number of words in any phrase and make sure to change the "/ select = X" property to the "X" in the text stimulus name

(4) Create a trial for the new phrase length by copy-pasting one of the existing trials

(4a) Add the required "TEXT_phraseX" stimuli to the "stimulustimes" list

(4b) Change the first "/ ontrialbegin" statement of the trial so that it refers to the counter containing the phrases with the new length e.g. "COUNTER_phrases_length7"

(4c) Repeat the following "/ ontrialbegin = [values.lastspacepos = search(substring ... values.lastphrase, 1)]" statements as often as the new phrase length

(4d) Make the last number in the just copied "/ ontrialbegin" statements increment by one with each statement, exactly as shown in the example trials.

I don't think you can get much more compact scripting in this matter. I see no way around creating separate trials for each phrase length (oh no, I just thought of one, so hold your breath). Also, since there are no loop expressions in Inquisit, you have to repeat the word selection routine for each word in a phrase.

Have fun,
Malte.

... and yet another slightly different approach contributed by yours truly,

~Dave

Ok, here we go. The attached script allows you to enter an arbitrary number of phrases als elements into a counter. Phrases may be of a maximum length of 15 words. All phrases in that counter are selected at random during the trial and displayed with incremental word count.

Problem is: the subject can quit each trial by a button press which is not very welcome. I've tried to fuddle around with the "/ isvalidresponse" and hoped Inquisit would be able to do this:

/ isvalidresponse = [(trial.TRIAL_showall.latency > values.wordcount * values.wordduration) && ((trial.TRIAL_showall.response==203) || (trial.TRIAL_showall.response==205))]

However, while Inquisit does record the response key at any given time the latency of this response appears not to be available. Instead, the latency of the previous trial is still contained in the trial attribute. Is that so? Dave, can you help me out on this one?

Bye, Malte

BTW, the problem would be fixed if Inquisit allowed to specifiy the responsetime by an expression. This is not possible, or is it?

Not currently, although I have requested this feature a while ago. Chime in!

~Dave

I wonder if there is a reason why, upon a keypress, the trial reports the current trial.trialname.response but not the trial.trialname.latency for that response to "/ isvalidresponse" and "/ iscorrectresponse". This way you are unable to provide any within-trial-feedback depending on reaction time.

Malte.

I had reported a similar bug back in November 2009 which has supposedly been fixed since: "trial.mytrial.latency property data is unavailable for evaluation in current trial via /iscorrectresponse (etc.) when /trialduration attribute is defined. Instead latency of previous trial is used."

What you observed appears to be closely related, so I strongly suggest you file a bug report via email.

Thanks,

~Dave