Hi Amie,
Thanks for the providing the whole picture - it's really helpful. I think FF comes really close to being able to implement this design, and I have an idea on what we could do to finish the last leg.
Just to make sure we are on the same page:
Presenting Audio and text/image at the same time
Yes, you can definitely present an audio and an image at the same time, as long as you put the image/text stimulus before the audio stimulus. In your design, you probably want to leave the barrier property of the audio stimulus untouched (that is, true by default). By placing the image/text stimulus before the audio stimulus, FF presents the image/text stimulus first, and then the audio stimulus. Because the presentation of the text/image is instantaneous, you effectively will be presenting both stimuli at the same time.
Keeping the "symbol" on the screen after the audio finishes playing
This is where it gets tricky. You are stuck between a rock and a hard place: if you put the symbol + audio on a separate trial than the last symbol, you get the barrier effect of the audio files nicely. That is, the trial containing only symbol + audio will accommodate the variable-length nature of your audio files, because the trial ends after the audio finishes playing. However, the challenge is now that your recording will be interrupted - you have to show the last symbol on a second trial, yoked together with the symbol+audio trial. Because there are two trials, there's going to be a gap between the audio recordings when the trials switch.
Alternatively, if you put the symbol + audio -> symbol on the same trial, you get the full uninterrupted recording, but it's impossible (for now) to tell FF to "keep showing the symbol" for 2 more seconds, given the variable lengths of audio files. In other words, FF doesn't understand a command like "ok, barriers are released, but wait for 2 more seconds before advancing to the next trial".
My proposed solution
Did I get your conundrum right? If so, I think the solution is now obvious at this point: trial templates already have a "delay" parameter, which delays the presentation of a trial by x seconds. I think we can expand the delay parameter to accept both a "starting" delay and a "end" delay", like this:
This will tell FF to wait 2 more seconds before advancing to the next trial, even when everything on the current trial is already done. This way, the background audio response continues to collect data for 2 more seconds after the audio file finishes playing.
I think this will be a feature of general value to researchers, and it happens to solve your issue too?
Thanks for the providing the whole picture - it's really helpful. I think FF comes really close to being able to implement this design, and I have an idea on what we could do to finish the last leg.
Just to make sure we are on the same page:Presenting Audio and text/image at the same time
Yes, you can definitely present an audio and an image at the same time, as long as you put the image/text stimulus before the audio stimulus. In your design, you probably want to leave the barrier property of the audio stimulus untouched (that is, true by default). By placing the image/text stimulus before the audio stimulus, FF presents the image/text stimulus first, and then the audio stimulus. Because the presentation of the text/image is instantaneous, you effectively will be presenting both stimuli at the same time.
Keeping the "symbol" on the screen after the audio finishes playing
This is where it gets tricky. You are stuck between a rock and a hard place: if you put the symbol + audio on a separate trial than the last symbol, you get the barrier effect of the audio files nicely. That is, the trial containing only symbol + audio will accommodate the variable-length nature of your audio files, because the trial ends after the audio finishes playing. However, the challenge is now that your recording will be interrupted - you have to show the last symbol on a second trial, yoked together with the symbol+audio trial. Because there are two trials, there's going to be a gap between the audio recordings when the trials switch.
Alternatively, if you put the symbol + audio -> symbol on the same trial, you get the full uninterrupted recording, but it's impossible (for now) to tell FF to "keep showing the symbol" for 2 more seconds, given the variable lengths of audio files. In other words, FF doesn't understand a command like "ok, barriers are released, but wait for 2 more seconds before advancing to the next trial".
My proposed solution
Did I get your conundrum right? If so, I think the solution is now obvious at this point: trial templates already have a "delay" parameter, which delays the presentation of a trial by x seconds. I think we can expand the delay parameter to accept both a "starting" delay and a "end" delay", like this:
Code:
"delay": {"start": 0, "end": 2}I think this will be a feature of general value to researchers, and it happens to solve your issue too?