Trials displaying longer than their set time?

[amiefairs]

Hi FindingFive, I have a study I am coding up but have noticed when I preview the exp that some of the stimuli stay on screen longer than they are supposed to. I have fairly rapid presentation of words and blank screens which alternate, and after a stream of words/blank screens, there is a question mark and an exclamation mark. The words should be on screen for 0.7 seconds and the blank screens display for 0.3 seconds, and then the question mark for 0.5 seconds and the exclamation mark for 1.2 seconds. As an example:
Blank screen -> words -> blank screen -> words -> blank screen -> words -> question mark -> exclamation mark
However, the final words screen (the third instance above) is always displayed for longer than 0.7 seconds and the exclamation mark is also displayed for longer than 1.2 seconds.
Originally I had background audio recordings on the question mark and exclamation mark trials, but whether I record a response or not makes no difference. Bizarrely, even though I have removed the responses, on these longer trials in the preview the little green 'response recorded' box comes up at the top of the screen.
I have the timings set at the trial level with no timings set at the stimulus level, and I originally had submission_point=FALSE set on all trials except the exclamation mark (assuming then I might have longer responses on the exclamation mark only). I've since removed submission point but this now makes each trial take longer (which doesn't surprise me) but I still have these extended trial lengths on some trials even if it is set to FALSE.
Do you know why the timings sometimes aren't respected?

[Ting]

Hi Amie,

This is a bit strange, especially in that it happens to only the third instance? Can I ask how you measured the *actual* length of the trials? Are those numbers coming from the CSV output?

[Ting]

As for why the "response received" prompt pops up even when you don't have a response: it's recording the duration of the trial. The duration of trial is considered data, so there's a "response received" message.

[amiefairs]

Thanks for clarifying the response received bit!
The actual length is 'recorded' by me counting out 'one mississippi, two mississippi', and I can do that for two mississippis on the words and three mississippis on the exclamation mark. Very scientific But then very obviously displayed for a long time, even though the csv output says they have been displayed for the correct amount of time coded.
I've only tried it on my laptop (a two year old top of the range dell inspiron) but with two different internet connections (one terrible, one mega fast), and the same problem happens with both.

[Ting]

Haha...I would like to count Mississippis too! I'll PM you with details on sharing the study with me and Lucy.

[Ting]

Hi Amie! I previewed your study and took the liberty to add submission_point back to most trial templates. I did observe what you described - so counting Mississippi is pretty darn accurate! Then I realized, if a trial is the last trial of a block, then FF *always* submits response data to the server to "save the progress". Could this explain why the second or third instance always seems to take a bit longer (depending on your procedure configuration), because they happen to be at the block boundary?

Is there a way to reconfigure your trial templates and procedure so that a single "trial" (your sequence of screens) is not split up into multiple blocks? The "alternate" pattern is not limited to two trial templates. So maybe you can link everything together?

[amiefairs]

Hi guys,

I'm back now trying to code this study and I am hoping for your wisdom on the best way to do it

I explained this above but here I am going to do it again. In this experiment participants see two words on screen at once, and they will see a list of these words, and then sometimes they will have to say something. They will either see two screens (of two words each), three screens, or four screens. Thus, there are three different patterns possible. The exact structure of each pattern is:
1. Blank screen (0.3 secs) -> words (0.7s) -> blank screen -> words -> question mark (0.5s) -> exclamation mark (1.5s)
2. Blank screen -> words -> blank screen -> words -> blank screen -> words -> question mark -> exclamation mark
3. Blank screen -> words -> blank screen -> words -> blank screen -> words -> blank screen -> words -> question mark -> exclamation mark

Firstly, to avoid the issue above, I will add an extra blank screen after the exclamation mark, with a true submission point, to send responses at that point. For info, I will have background audio running on at least the question mark and exclamation mark screens. In fact, now I think of it, would it better to combine them into one trial type and set a delay for the onset of the exclamation mark to be 0.5s relative to the onset of the trial, such that it is then one longer audio response that is recorded versus two different audio files?

However, I am trying to work out the best way to create these patterns. Because these three different 'trial' types (the sequences of screens) have different lengths, should I specify each one as a block, and then in block sequence randomise the orders of the blocks? I have maybe 100 of these trials in the experiment so this would make 100 of these blocks. That way I am sure that the sequence of screens will definitely be fixed and I shouldn't have timing issues/response received issues. However, this is tedious to code (though if it is necessary then so be it).

Or, would it be better to create three different block types - one type for each of the patterns - and then randomise their order? The only problem is that I don't want a whole block of one pattern type trials, followed by only another pattern type trials, but they need to be intermixed. I think setting up three blocks corresponding to the patterns won't randomise in this way?

Or, is there another way to manage this that you know of that I just haven't thought about?

Thank you in advance for any inspiration you can send me! Sorry there are so many questions.
P.S. I saw you now have an onset detection feature in background audio and this is amazing and will save me so many hours of work! Thank you so so much!

[amiefairs]

Just to add - I found the 'display multiple stimuli per trial' tutorial and have implemented that to combine the question mark and exclamation mark trials into one, so I have only one background audio response recorded (so glad to find all this stuff!) However, even though I have both stimuli set with the same size, and center alignment, and both coded to be in location 5,5, they appear slightly out of sync. I thought this might be because their timings could mildly overlap (as one is set to display for 0.5, and the other is set to have a delay of 0.5 and a duration of 1.2) so I removed any overlap (now the first has a duration of 0.45 and the second has a delay of 0.55), but I'm still having this issue. It is like the question mark displays in the top center of the screen and the exclamations marks in the bottom centre. Do you know how I can fix this?

[Lucy - FF Researcher Support]

Hi Amie,

Can you explain more about your "words" trials? Is this from a trial template with multiple different stimuli, so that you would be using trial yoking (https://news.findingfive.com/2019/07/17/...ed-trials/) to get the correct stimulus on each sequence of trials?

Also, for your issue with having the question mark and exclamation mark in different locations: This is the reality of having multiple stimuli on the same trial--even if you set the location to be the same, they will appear in slightly different places. FindingFive wants to avoid overlap of stimuli. You should have these stimuli on different trials to avoid this problem.

[amiefairs]

The words are one stimulus each - so one stimuli text screen per two words. For a 'trial' though they are defined as a trial template in their order, for example:
"items1": {
"type": "basic",
"stimuli": ["crainteJasmin", "rogneMoment"],
"duration": 0.7,
"submission_point": false
}
(having sent this to you now I have realised I have made a slight error in timing, though not important here). I will use trial yoking but I have fixed orders of some word screens - so fixed orders of some trials - and others can be random. This is because, for example, some word screen 'prime' others, which is why they are in a fixed order, but if we think of the primes + target as a group then those groups of trials can be randomised.

Ah, that's frustrating about the question mark and exclamation mark, as the tutorial says they will display in the same location (maybe you could update the tutorial to explain this, as it sounds like they should display in the same place where one 'overrides' the other). I could split them over two trials but then I don't think I can have a background audio response which spans the length of both trials , is that correct? As that is a necessity to ensure we collect our data.