FAQ #3 - Simultaneous Presentation of Audio and Other Stimuli

[amiefairs]

That would be great, I'm looking forward to it!

The background_audio does record during the audio playing using chrome on my computer, so either it isn't working with firefox or it just isn't working on a specific computer - we'll investigate and get back to you in case you are interested.

But auto_advance still doesn't work. Just to be very clear, we have a trial template being displayed that is coded as:
"audios_practice": {
"type": "basic",
"stimuli": [["symbol","p1"], ["symbol","p2"]],
//"duration": 4,
"auto_advance": false,
"responses": ["voiceRecording"],
"submission_point": false
}

This reads in the symbol (of type 'text') to show on screen and two sounds (both audio; this is a minimal toy version of the experiment while we iron out the bugs). I have explicitly set barrier = true on the audio and tried to have auto_advance = true and false; when true the audio ends but the symbol stays on screen and I have to exit the experiment, when false there is a continue button (which we don't want). If I explicitly set barrier = false in the audio then when auto_advance = true I have to exit the experiment because it just continues to show the symbol, and when auto_advance = false a continue button shows immediately at the onset of audio (but the audio does play). So as far as I can tell it they aren't interacted how we would like them.

[Ting]

Amie, the specific interaction / combo of features you want do seem not readily possible. We'll look into a solution for you, besides the delay end feature! Hang tight!

[Ting]

Hi Amie & Bissera,

We have created a new feature for solving your exact problem, and we think it'll have more generalizable uses for other researchers as well. It occurred to us that the key to implementing your design is making the duration of the audio recording relative to the duration of the audio stimulus. We have done exactly that!

Overall setup
On a trial of interest, you should:

• Place the text stimulus before the audio stimulus so that they show up at the same time
  
• Set "barrier": false in the audio stimulus so that it won't block the audio response
  
• New feature: Set the duration of the background audio response to:
  
  Code:

  "duration": "%sgroup:audio+2.0"

That is, the duration of the audio response will be 2 seconds plus whatever the duration of the stimulus of the group "audio" is, on the same trial.

Stimulus Group
The "stimulus group" thing is also a new feature, but it's easy to do: just add

Code:

"group": "audio"

to all the audio stimuli that are going to appear on the trial of the interest. The end result is that the audio response will look for a stimulus of the group "audio" on the trial, and then set its duration to the duration of that audio stimulus plus 2 seconds.

Important: Special Previewing Trick
If you just did all of that and hit preview, you'll notice that it won't work. This is because FindingFive has recently implemented some safeguarding mechanisms so that beta changes to the Study Grammar features, like the one we are working on for you, don't affect ongoing studies. To make it work, you'll need to:

• Hit the preview button and let the website load
  
• Go to the URL bar and add "&live=1" to the end of the URL
  
• Hit Enter and let the website load again
  

Only with "&live=1" added to the URL will you be able to use this new feature. Once you have confirmed that this works for you without breaking other aspects of your study, we'll move the new feature into the Study Grammar officially.

Give it a try and let us know? We are really glad to receive this feature request - it opens up a paradigm of how we would handle other complex features too! Thanks!

[amiefairs]

Wow thank you for this! I only just saw this update so I will implement this and test it by the end of the week and get back to you (hopefully sooner!)

[Ting]

Hi Amie - no rush. Actually, if you get to this after Wednesday, the "&live=1" part will be no longer necessary. We had to apply an emergency fix which required us to publish this feature officially first. So, well, one less thing for you to do!

[amiefairs]

Hi Ting,

Ok, we have tried to implement it and it isn't working, and I think maybe we have done something unnecessary Instead of having a background audio last 2 seconds after the audio we play, instead the audio is now truncated so the entire audio sentence doesn't actually play all the way through, it just cuts after around 1 second.

Below is the code we are using, in a minimal way, and maybe you can see where we are going wrong?

#### stimuli
# symbol
{
"type": "text",
"content": "♢",
"size": "70px",
"alignment": "center"
}

# p1
{
"type": "audio",
"content": "p1.mp3",
"visible": false,
"delay": 0.3,
"barrier": false,
"group": "audio"
}

# p2
{
"type": "audio",
"content": "p2.mp3",
"visible": false,
"delay": 0.3,
"barrier": false,
"group": "audio"
}


### response
# voiceRecording
{
"type": "background_audio",
"duration": "%sgroup:audio+2.0",
"onset_detection": true
}



### trial templates
"fixation_cross_practice": {
"type": "basic",
"stimuli": ["fixation", "fixation"],
"duration": 1.5,
"submission_point": false
},

### this is the text + audio template
"audios_practice": {
"type": "basic",
"stimuli": [["symbol","p1"], ["symbol","p2"]],
"responses": ["voiceRecording"],
"submission_point": false
},

"blank_catch_practice": {
"type": "basic",
"stimuli": ["blankScreenSmall", "blankScreenSmall"],
"duration": 1,
"submission_point": true
},


#### procedure
"practiceBlock": {
"trial_templates": ["fixation_cross_practice", "audios_practice", "blank_catch_practice"],
"pattern": {"order": "alternate_random"}
},

Is it ok to group the text and audio together in a trial template? We thought this was the only way to ensure that they both stay on screen at the same time, but maybe that doesn't work here?

If you have any insight into why the audio is now truncated we'd love to find out The background audio does record though (though not the extra two seconds), so there is background audio recording on each trial.

If it is easier, I can also add you as a collaborator on the study.

[Ting]

Thanks for the feedback, Amie. Something does seem off. We'll look into this and share a working study with you.

[amiefairs]

It works!!!
Thank you so much for the template!
I have no clue why we had errors before though, the only two things I changed in our code are that instead of:
"group": "audio"
I wrote: "group": "group1" (and correspondingly changed "audio" to "group1" in the background_audio).

I also removed "onset_detection": true from the voice recordings for the test, because I thought maybe that interacts somehow, but now I put that line back in and it still works, so I really don't know how it was broken before... I suspect maybe calling things 'audio' in two places wasn't great? Though Bissera also tried it using different names and it still didn't work.

Anyway, it works now! We will also be able to let you know whether the onset_detection:true will work in this case because I can hear the audio file in the background_audio recording, so that could trigger the onset_detection, but it may not if it triggers only from the mic. I will let you know about this because it is extremely useful info for people who record speech production (like me), to know whether the onset_detection will work (it saves us - very literally - hundreds of hours).

[Ting]

That's awesome!! We did fix one tiny bug and that's probably why.

Let me know how robust the onset detection feature is! We are quite curious about it too.