Timing resources: inline after 'end of proc' responses

19 views
Skip to first unread message

Chris Brozdowski

unread,
Sep 21, 2021, 4:17:45 PMSep 21
to E-Prime
Hi all, 

I had a problem recently that I'll describe below. I think I've found the solution, but I'd also welcome alternatives. First, I still wanted to gather the resources I used in the process. David has some great posts about timing, but the pstnet links from years back don't always work.
  1. Steps to reduce onset delay
  2. Prerun/postrun
  3. Input mask time limits: End of procUntil feedback 
  4. David on Prerun + Prerelease + Inline (2016)
  5. David on Inline unexpectedly after object with prerun (2016)
  6. David on Prerelease + Inline (2018)
In my own case, I have a proc with all cumulative timing and prerelease set to 'same as duration' for an fMRI experiment where I care about small timing delays. I have a target object with a response that permits input until the end of the proc. I then have a fixation of variable length before an InLine that selectively gathers accuracy. 
  1. Target stimulus (permit response until end of proc)
  2. Fixation (duration controlled by stimulus list feature)
  3. InLine script to sum accuracies for a subset of conditions, not triggering for responses during fixation above.
Even with pre-run generation set to BeforeObjectRun, my InLine was only able to access accuracy if the response was given during the target, not during the fixation. For participants with delayed responses, the InLine script was falsely collecting 'no response' and showing me "00" for cumulative accuracy. By adding a 0ms duration secondary fixation, I now get better accuracy collection.
  1. Target (still end of proc)
  2. Fixation (variable duration)
  3. Fixation (0 ms, causing some permissible timing delays)
  4. InLine script that does trigger for the first fixation above.
Please let me know if you can think of a more elegant solution, hopefully one that will not interfere with timing.

Cheers,
Chris

David McFarlane

unread,
Sep 23, 2021, 2:27:31 PMSep 23
to e-p...@googlegroups.com
Chris,

Thanks much for gathering together this info!

Thoughts on your current case ...

Looking at the original design of your Procedure:

1. Target stimulus (permit response until end of proc)
2. Fixation (duration controlled by stimulus list feature)
3. InLine script to sum accuracies for a subset of conditions

With PreRelease of Fixation set to "(same as duration)", your InLine
code will start running as soon as Fixation finishes its onset. So if
Target does not get a response, then Fixation will appear and the InLine
will run before any response comes during Fixation.

Adding another Fixation (or a Wait) with a Duration of 0 right after the
Fixation does indeed fix this, as it essentially does the same thing as
setting the PreRelease of Fixation to 0. I have used that trick myself
in the past, before I better understood how timing in E-Prime works :).
But try removing the second Fixation and setting Fixation PreRelease
to 0 and see if I know what I am talking about.

This of course holds up everything until Fixation reaches its Duration
no matter when a response comes. Probably good enough in most cases,
but if you really wanted to let the program start processing the next
thing after presenting Fixation and seeing a response, then you could do
something like this in your InLine:

Do While Target.InputMasks.IsPending
Loop
' Proceed with code to sum accuracies, etc. ...

Best,
-- David McFarlane


On 2021-09-21 Tue 4:17 PM, Chris Brozdowski wrote:
> Hi all,
>
> I had a problem recently that I'll describe below. I think I've found
> the solution, but I'd also welcome alternatives. First, I still wanted
> to gather the resources I used in the process. David has some great
> posts about timing, but the pstnet links from years back don't always work.
>
> 1. Steps to reduce onset delay
> <https://urldefense.com/v3/__https://support.pstnet.com/hc/en-us/articles/229355067-TIMING-Steps-to-reduce-large-OnsetDelay-values-19370-__;!!HXCxUKc!j5v9GLzc7incsngr9E8zmFopSW4r0G5JyrH48saDTph0Ses1fFD-heA1AdFSZ-FR$>
> 2. Prerun/postrun
> <https://urldefense.com/v3/__https://support.pstnet.com/hc/en-us/articles/115011423508-TIMING-Pre-Run-and-Post-Run-Generation-22854-__;!!HXCxUKc!j5v9GLzc7incsngr9E8zmFopSW4r0G5JyrH48saDTph0Ses1fFD-heA1AUpOR1N0$>
> 3. Input mask time limits: End of proc
> <https://urldefense.com/v3/__https://support.pstnet.com/hc/en-us/articles/360020474554-INFO-InputMask-TimeLimit-end-of-proc-option-18043-__;!!HXCxUKc!j5v9GLzc7incsngr9E8zmFopSW4r0G5JyrH48saDTph0Ses1fFD-heA1AV6ofaLa$>,
> Until feedback
> <https://urldefense.com/v3/__https://support.pstnet.com/hc/en-us/articles/360017264114-INFO-InputMask-TimeLimit-until-feedback-option-19098-__;!!HXCxUKc!j5v9GLzc7incsngr9E8zmFopSW4r0G5JyrH48saDTph0Ses1fFD-heA1AUu4ziPq$>
>
> 4. David on Prerun + Prerelease + Inline
> <https://urldefense.com/v3/__https://groups.google.com/g/e-prime/c/SBZ5pL0z8NE/m/7eas4yHOAAAJ__;!!HXCxUKc!j5v9GLzc7incsngr9E8zmFopSW4r0G5JyrH48saDTph0Ses1fFD-heA1AYPZPPBp$> (2016)
> 5. David on Inline unexpectedly after object with prerun
> <https://urldefense.com/v3/__https://groups.google.com/g/e-prime/c/Liej8Ik83sU/m/BEaCVt4CBQAJ__;!!HXCxUKc!j5v9GLzc7incsngr9E8zmFopSW4r0G5JyrH48saDTph0Ses1fFD-heA1AYbbf_xp$> (2016)
> 6. David on Prerelease + Inline
> <https://urldefense.com/v3/__https://groups.google.com/g/e-prime/c/hkEndArSIEA/m/QeO24BzuAgAJ__;!!HXCxUKc!j5v9GLzc7incsngr9E8zmFopSW4r0G5JyrH48saDTph0Ses1fFD-heA1AfYtgtcg$> (2018)
>
> In my own case, I have a proc with all cumulative timing and prerelease
> set to 'same as duration' for an fMRI experiment where I care about
> small timing delays. I have a target object with a response that permits
> input until the end of the proc. I then have a fixation of variable
> length before an InLine that selectively gathers accuracy.
>
> 1. Target stimulus (permit response until end of proc)
> 2. Fixation (duration controlled by stimulus list feature)
> 3. InLine script to sum accuracies for a subset of conditions, not
> triggering for responses during fixation above.
>
> Even with pre-run generation set to BeforeObjectRun, my InLine was only
> able to access accuracy if the response was given during the target, not
> during the fixation. For participants with delayed responses, the InLine
> script was falsely collecting 'no response' and showing me "00" for
> cumulative accuracy. By adding a 0ms duration secondary fixation, I now
> get better accuracy collection.
>
> 1. Target (still end of proc)
> 2. Fixation (variable duration)
> 3. Fixation (0 ms, causing some permissible timing delays)
> 4. InLine script that does trigger for the first fixation above.

Chris Brozdowski

unread,
Sep 23, 2021, 4:19:00 PMSep 23
to E-Prime
Hi David,

That loop code would be a very smart fix, thank you! It holds on the response while still (I think) permitting prerelease to have the desired effect.

Our local imaging team was more responsive than I expected when I reached out yesterday asking to try out my solution on their equipment. It works with minimal delays (thanks to cumulative timing), so I think I'll keep as is for now. "If it ain't broke, don't fix it" approach, but I'll definitely try out this loop next time I'm building something.

All the best,
Chris

Reply all
Reply to author
Forward
0 new messages