Trials displaying longer than their set time?

[Ting]

Hi Amie,

The tutorial is indeed a bit confusing. What it meant to say is that different stimuli can be allocated to the same location, but each of them will nevertheless occupy a different space (within that location). We can review whether this is a reasonable behavior. Maybe it isn't.

The most efficient way to code up your study might have to involve using an external tool - perhaps it's easier to create a "movie" for each presentation sequence? It sounds like the sequences (under all three variations) are hard coded anyway. One can probably do it in PowerPoint by creating a sequence of slides that present the entire sequences of stimuli, and then export it as a video file. You can then upload the video files to FF and just create a single "trial" for each movie, with a background audio attached to it.

Alternatively -

Will the ability to mix trials between blocks on FF solve your issue as well? The way I see it, you can create yoked trials for each sequence, put them into three blocks, and then mix up the blocks? We are interested in developing this feature, since it will likely come up again in other researchers' designs.

Let us know!

[amiefairs]

I think it can be reasonable behaviour, but at least how I read the tutorial I assumed they would also show up on screen in the same space. It could just be me misunderstanding though. However, the researchers I am building this for have said it's not too much of an issue, as having one long audio recording is most important.

I like your powerpoint idea! I may consider it, though for right now I have gone about this in a horrible way to look at - I instead make each stimuli a trial template and then create new blocks for each trial sequence, and then chain the blocks together. For this specific experiment there are only two possible experiment lists (so I don't need to worry about making each sequence occur in a random order), so I'll take advantage of assigning participants to groups and then just define the block order. It's just very ugly, but it absolutely works, and that is what is important!

I'm not sure if I understand your between blocks comment. In a previous study I yoked trial templates having randomised them first, put them into 5 separate blocks, and then randomised the blocks, so that participants (in theory) all saw a different trial sequence. Is that the kind of thing you are suggesting here?

As an aside, something I would now really like as a new development would be batch uploading for text files. I am manually creating new stimuli, which are of type 'text', and then putting the two words which display in each stimulus. It would be very cool if there were a way to upload a csv file with all the words in it, and they would be automatically put into stimuli files (similarly to the way you do it for picture uploads).

[Ting]

We'll get back to your other comments a bit later, but FF has always supported uploading a CSV file to create stimuli! It's covered in the crash course: https://news.findingfive.com/2019/03/26/...y/#stimuli

[Ting]

Hi Amie,

Regarding my comment on "randomizing trials between blocks", I may have misunderstood your design. But let me try to clarify my thoughts first, and then you can tell me where I am wrong. =)

My interpretation was that you needed three types of "yoked trials", as illustrated by your three different sequences. Each of them represents a particular way of displaying stimuli and collecting responses.

Each sequence corresponds to many different actual instances of such trials, because there are different stimuli. So, using the "alternate_random" trick, you can create all instances of a single sequence type fairly easily.

The problem, as I perceived it, is that by using "alternate_random", you are confined to presenting instances of a single sequence type in a single block. In other words, you may code three blocks, each representing a sequence type that you want, but each block must be presented in its entirety before another block can be presented, meaning that all yoked trials of a particular sequence type will be presented altogether, and then another sequence type, and then another.

I don't believe that's what you want, right? You want the trials of all three sequence types to be mixed together.

That's why I suggested, that if we have a way to mix trials between blocks, then your design can be implemented rather effortlessly.

Where did I get this wrong?

[amiefairs]

Hi Ting,

I'm so sorry I missed the email about this response and haven't replied!

Yes, you are exactly right! Somehow I did not understand your previous reply So yes, I have three different sequences and if I code them using alternate random then they end up in different blocks, and yes being able to mix trials/sequences between blocks would be fantastic! So yes, if this can be added to FindingFive as a new feature this is something I would definitely make use of. Especially because I actually like, in general experiments, to have entirely random sequences of stimuli presentation. In my previous FindingFive experiment I randomised trials within a block and then randomised the block order, but if trials could be mixed between blocks then there could be something approaching full randomisation.

Now though I have a related but slightly different question - how many trials/screens can I display with submission point = false? Timing is so critical on the study I am (still) coding that I have worked out that instead of making a block of each sequence, it is better to chain sequences within one big block. At some point though I need to have a screen with submission_point = true because I need to send the data back. Do you have a guideline on how many screens/trials I could display before having this submission_point = true screen? This relates to one of the issues when I started this thread, about how at the end of a block responses are recorded resulting in a longer final 'screen', so I need to make my blocks longer to get around this. But I don't want to make them so long there are issues with data caching in the experiment...

---

And thanks for the crash course stimuli batch upload. No idea how I missed that as I have done the crash course But you have saved me hours of work, thank you!

[Ting]

Hi Amie,

Sorry about the late reply - the last weekend was Chinese New Year so I was a bit, ugh, unproductive. For your questions:

1. OK - we'll get started on developing the feature for randomizing trials across blocks. Hopefully we can get this done by the end of February.

2. Great question. In theory it doesn't matter that much - anything below 20 trials with no submission in a row would probably be fine. It really depends on how much data are collected on each trial. For example, if every trial collects a full minute of audio data, then obviously you'd probably want to save that every couple of trials. But if it's just choices, text, and etc, it can arguably go on very long without submission. The caching of participant data is fairly robust, and in theory, the upper limit is rather humongous, to the extent that no reasonable behavioral experiment would ever trigger it.

[amiefairs]

Happy now very belated New Year! I'm glad work was unproductive because hopefully that means you were celebrating

Randomising across blocks: excellent! So excited to use that in the next study.

Data caching: this is the best news you could have given! I want to collect around 1 second of audio and wanted to have three of these audio files recorded before submitting to the server, so I can do this and not have to worry (obvs will test it out too). But really good to know, you've made my day!

[Ting]

Hi Amie,

It occurs to me that maybe an improved version (we can probably work on this rather quickly) of the tokenized text stimulus would be the best solution for your designs? The tokenized text stimulus has a "singleton" mode that displays one word/token at a time. You will essentially enter your sequences as a list of "tokens", where blank screens are just an empty string as a token. Then, FF can "play" the sequence for you, simulating the effect you want within a single stimulus.

The "improvement" that needs to be done is to allow a different duration for each token. Right now, the tokenized text stimulus takes a single number for "token_duration", but that can be easily expanded to accept a list of timings.

This wouldn't work for studies where user response is only allowed when the "target" token appears, but since you are just collecting audio recordings passively, you'll just collect a longer recording. 

The huge benefit is that you can now create all trials in a single block now, and randomize them properly. Right?