connecting between e-prime and a socket device

24 views
Skip to first unread message

ronis...@gmail.com

unread,
Nov 4, 2021, 1:17:16 PM11/4/21
to E-Prime
Hi,

We're trying to send triggers from e-prime to a VR application via a socket devise. Specifically, we want to sent strings at the onset and at the offset of each trial objects. This way we want the VR application to play certain videos according to e-prime's commands. We use an inline before each object:

Socket.WriteString "Object_Onset"
Socket.WriteString "Object_Offset"

We also defined OnsetTime and OffsetTime in the task events properties of each object.

We currently see both triggers ("Object_Onset" and "Object_Offset") sent to the socket, but both are sent at the same time - onset of the objects.

We would appreciate your help.

Thanks!
Roni

David McFarlane

unread,
Nov 4, 2021, 3:58:02 PM11/4/21
to e-p...@googlegroups.com
Roni,

Excellent. You already got Socket communications to work -- as I like
to say, "Better to start from success than from failure." Now you just
want this to happen at the right time.

To review ...
- You added a Socket device to your Experiment object.
- You added two Task Events to your stimulus object, let's call it StimObj.
- You have one task event linked to StimObj.OnsetTime; that task event
does a Socket.WriteString, with Delay 0 and Custom value "Object_Onset".
- You have a second task event linked to StimObj.OffsetTime; that task
event does a Socket.WriteString, with Delay 0 and Custom value
"Object_Offset".

What confuses you is that "offset" in this case practically coincides
with "onset". This is actually by design, and needs some discussion to
understand why and then how to fix this.

"Offset" in E-Prime has a specific technical meaning: It indicates the
time at which *processing* of an object ends, which may (and often does)
differ from when a stimulus object ends its presentation. Namely, for
Event timing mode, we have

obj.TargetOffsetTime = obj.OnsetTime + obj.Duration - obj.PreRelease

(for Cumulative timing mode, simply use .TargetOnsetTime instead of
.OnsetTime). Note that .TargetOffsetTime specifies the *scheduled*
offset time -- the actual OffsetTime of course will depend on several
hardware & software factors, but generally will closely match
TargetOffsetTime.

Now, when you have PreRelease set to "(same as duration)" (which is the
default), you see the result that
obj.TargetOffsetTime = obj.OnsetTime (!)
So in this case, offset will happen immediately upon onset -- i.e.,
*processing* (as opposed to *presentation*) of obj will end as soon as
possible after onset and allow processing of the next object to start,
which can improve timing performance.

But in your case this generally desirable behavior interferes with the
timing of your Socket signals. You could fix this in a couple of ways:

(1) Simply set PreRelease to 0. That will take care of it, at the cost
of somewhat reduced timing performance (which may not matter for many
task designs). Alternatively, set PreRelease to some small value, e.g.,
100 -- that would allow an extra 100 ms for E-Prime to prepare the next
stimulus object, and during analysis you would just know to add 100 ms
to the placement of the OffsetTime markers.

(2) Use the OnsetTime of the following stimulus object to mark the end
of presentation of the previous object. Indeed, in many cases this
would better reflect the true end of presentation of the previous
stimulus. E.g., visual objects do not actually disappear at the
OffsetTime, but remain visible until replaced by another visual
stimulus, i.e., at the OnsetTime of a following visual stimulus.

For more discussion of OnsetTime, OffsetTime, and related matters,
please see the threads at groups.google.com/d/topic/e-prime/OeiZ00V9SRc
, groups.google.com/d/topic/e-prime/6jTtoQ8qENg , and
groups.google.com/d/topic/e-prime/luXrAFWy7Sc .

-- David McFarlane

Spape, Michiel

unread,
Nov 4, 2021, 7:09:28 PM11/4/21
to e-p...@googlegroups.com
Hi,
It could be me, but I think you're way ahead of what was actually achieved. That is, I took the post as saying:
- They added a socket device to their experiment object
- They added an inline before playing the video
- The inline wrote a string "Object_onset" then "Object_offset"
- These strings were indeed sent before the video, literally these two strings in sequence.

Now, the simplest way to make it work would be to send an inline "Object_onset", then play the video, then send "Object_offset", although that would be misguided because the string "Object_onset" would be send just before the actual video started loading/playing and Object_offset just after it did (but might still be on the screen). Using task events would indeed be the better way to go about it, but so far I haven't found easy tutorials on firing specific bits of scripts on task events (although I have never used socket devices as task events; maybe it just works!). In my experience, once a video is done being played, it tends to stay on the screen, so the 'offset' from a participant point of view is AFTER the video (at least if PreRelease == 0). If the video then has an inline coming straight after, you might write
Socket.WriteString "OffsetTime_OnsetTimeWas" & cstr(Object.OnsetTime - clock.read)
So an event is written AT the time the video is done playing (namely when the event is written), and it includes when the relative onset of the video was (it only being clear AFTER the video is shown, not before, as seemed to have been assumed in the OP).

That's a bit of a dirty hack, of course, but it seems the easiest implementable with regards to what is there. Personally, I would hook it all up to the object coming AFTER the video (with a task event), because it's the only point we know for sure something new has actually been shown on the screen.
HTH,
Michiel
--
You received this message because you are subscribed to the Google Groups "E-Prime" group.
To unsubscribe from this group and stop receiving emails from it, send an email to e-prime+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/e-prime/f77e714e-e9b2-fd12-dd2a-6e8ee8c5aa3d%40msu.edu.

Spape, Michiel

unread,
Nov 4, 2021, 7:21:01 PM11/4/21
to e-p...@googlegroups.com
Hi,
Sorry, I forgot to say the following about more practical considerations when it comes to VR. I've worked quite a bit with VR, E-Prime, and time-sensitive experiments, and from my experience, there's quite a bit of delay between when you want something to be shown on the screen and when it's actually shown. That is, here (https://internal-journal.frontiersin.org/articles/10.3389/fnhum.2017.00079/full) we made specific comparisons between VR, a normal screen, and a virtual screen in a virtual replication of our lab, and we had to go through all sorts of hoops to measure the screen latency between com port triggers and visual input. In fact, we used a light sensor, stuck with a bit of gum to the HMD to find out the delay was in the range of 40 ms or so (if memory serves) in VR conditions compared to a delay in a normal Unity application of ca 80 ms. Point being both were quite substantial.
Anyway, aside from the amusing anecdote, I thought you might appreciate this if you're using E-Prime specifically to know that something is hyper accurate in timing - its USP after all - you'll still be wanting to test this sort of thing if that is important to you. Better test than blindly trust.
Best,
To view this discussion on the web visit https://groups.google.com/d/msgid/e-prime/HE1PR07MB4346184B28C2E83F79EFBC2AFA8D9%40HE1PR07MB4346.eurprd07.prod.outlook.com.

David McFarlane

unread,
Nov 5, 2021, 9:54:43 AM11/5/21
to e-p...@googlegroups.com
Michiel, Yep, I saw "task events" in the third (second?) paragraph and
ran with that, completely overlooking "We use an inline" at the end of
the first paragraph. Thanks for filling in that angle.

Roni, I hope you find something useful in all this :).

-- David McFarlane


On 2021-11-04 Thu 7:20 PM, Spape, Michiel wrote:
> Hi,
> Sorry, I forgot to say the following about more practical considerations when it comes to VR. I've worked quite a bit with VR, E-Prime, and time-sensitive experiments, and from my experience, there's quite a bit of delay between when you want something to be shown on the screen and when it's actually shown. That is, here (internal-journal.frontiersin.org/articles/10.3389/fnhum.2017.00079/full ) we made specific comparisons between VR, a normal screen, and a virtual screen in a virtual replication of our lab, and we had to go through all sorts of hoops to measure the screen latency between com port triggers and visual input. In fact, we used a light sensor, stuck with a bit of gum to the HMD to find out the delay was in the range of 40 ms or so (if memory serves) in VR conditions compared to a delay in a normal Unity application of ca 80 ms. Point being both were quite substantial.

Roni Shafir

unread,
Nov 5, 2021, 2:35:00 PM11/5/21
to E-Prime
Thank you both!

We're actually still having problems making this work. Just to make sure I'm clear - we want eprime to send triggers to Unity so that Unity can play the VR segments in accordance with the timing defined in e-prime. For instance, we want Unity to display a fixation for 2 seconds at the beginning of each trial. We need inlines that "tell" unity when and for how long to play it.

Now, we moved the task events and we're using inlines before and after each event. We can successfully send triggers but for some reason the duration of the videos is not correct. 

I've attached the e-prime file we're working with (basic task that has 2 trials: 2 seconds ITI ---> 3 seconds pain ----> 1 second jitter), as well as the output triggers. For some reason, the duration of the iti is the duration of the jitter, the duration of the pain is that of the ITI, and the duration of the jitter is that of pain. We're obviously missing something here...

Please let me know if you have any suggestions.

Thanks again!
Roni


--
You received this message because you are subscribed to a topic in the Google Groups "E-Prime" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/e-prime/uyVumilAaMc/unsubscribe.
To unsubscribe from this group and all its topics, send an email to e-prime+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/e-prime/c635ebab-3b46-512c-659d-757beda9b9d2%40msu.edu.
output.png
ParallelTrigger_Test.es2

Hans Revers

unread,
Nov 8, 2021, 5:00:13 AM11/8/21
to e-p...@googlegroups.com
Dear Roni,
We have developed a communication tool to link E-Prime to VR (Unity) that makes use of socket communication.
We have used it in two experiments, so far. One showing 360-degree videos, one showing 360-degree images.
Short questionnaires were presented following each video/image in the VR environment that could be answered via the VR controller. Answers were sent back to E-Prime.
If I understand your question correctly, this communication tool does more-or-less what you are trying to achieve.

We intend to publish the tool with documentation and sample E-Prime experiments on GitHub, along with a short IEEE paper. We just have not gotten around to that yet.

If you like, I can share these files with you so you can judge whether it could be of use to you. Let me know.
Best,
Hans Revers




You received this message because you are subscribed to the Google Groups "E-Prime" group.
To unsubscribe from this group and stop receiving emails from it, send an email to e-prime+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/e-prime/CALq6LK1uNAu7XokUb1RG90ywMxF%3Dhq_3hjAJok1tL%3D73Ua9VCQ%40mail.gmail.com.

Roni Shafir

unread,
Nov 8, 2021, 8:09:15 AM11/8/21
to e-p...@googlegroups.com
Hi Hans,

That would be great, thanks so much!

We are now thinking to send triggers to Unity only at the beginning of each event, which should be easier. Any information from someone who did something similar before will be very helpful.

Thanks again,
Roni



בתאריך יום ב׳, 8 בנוב׳ 2021 ב-5:00 מאת Hans Revers <hans....@gmail.com>:

McFarlane, David

unread,
Nov 8, 2021, 8:51:50 AM11/8/21
to e-p...@googlegroups.com
Roni,

Thank you for stripping this down to a minimal example. That makes it easy to examine. I wish more people would do this.

Your task program behaves exactly as designed. You have some confusion about how PreRelease works. Please read about PreRelease in the documentation that comes with E-Prime. Also, search for "prerelease" in this Group to find threads that discuss this. Or reread the explanation of PreRelease in my first post in this thread. Hint: Try setting PreRelease to 0 on all of your stimulus objects.

-- David McFarlane

________________________________________
From: e-p...@googlegroups.com <e-p...@googlegroups.com> on behalf of Roni Shafir <ronis...@gmail.com>
Sent: Friday, November 5, 2021 2:34 PM
To: E-Prime


Subject: Re: connecting between e-prime and a socket device

Thank you both!

We're actually still having problems making this work. Just to make sure I'm clear - we want eprime to send triggers to Unity so that Unity can play the VR segments in accordance with the timing defined in e-prime. For instance, we want Unity to display a fixation for 2 seconds at the beginning of each trial. We need inlines that "tell" unity when and for how long to play it.

Now, we moved the task events and we're using inlines before and after each event. We can successfully send triggers but for some reason the duration of the videos is not correct.

I've attached the e-prime file we're working with (basic task that has 2 trials: 2 seconds ITI ---> 3 seconds pain ----> 1 second jitter), as well as the output triggers. For some reason, the duration of the iti is the duration of the jitter, the duration of the pain is that of the ITI, and the duration of the jitter is that of pain. We're obviously missing something here...

Please let me know if you have any suggestions.

Thanks again!
Roni


On Fri, Nov 5, 2021 at 9:54 AM David McFarlane <mcfa...@msu.edu<mailto:mcfa...@msu.edu>> wrote:
Michiel, Yep, I saw "task events" in the third (second?) paragraph and
ran with that, completely overlooking "We use an inline" at the end of
the first paragraph. Thanks for filling in that angle.

Roni, I hope you find something useful in all this :).

-- David McFarlane


On 2021-11-04 Thu 7:20 PM, Spape, Michiel wrote:
> Hi,

> Sorry, I forgot to say the following about more practical considerations when it comes to VR. I've worked quite a bit with VR, E-Prime, and time-sensitive experiments, and from my experience, there's quite a bit of delay between when you want something to be shown on the screen and when it's actually shown. That is, here (internal-journal.frontiersin.org/articles/10.3389/fnhum.2017.00079/full<https://urldefense.com/v3/__http://internal-journal.frontiersin.org/articles/10.3389/fnhum.2017.00079/full__;!!HXCxUKc!kW4wT5yhVthr0KL1Mn_anGWItAOWSNG-TfahsGy1S03ZIMgK7RtAsV22PqiVMr-f$> ) we made specific comparisons between VR, a normal screen, and a virtual screen in a virtual replication of our lab, and we had to go through all sorts of hoops to measure the screen latency between com port triggers and visual input. In fact, we used a light sensor, stuck with a bit of gum to the HMD to find out the delay was in the range of 40 ms or so (if memory serves) in VR conditions compared to a delay in a normal Unity application of ca 80 ms. Point being both were quite substantial.

> For more discussion of OnsetTime, OffsetTime, and related matters, please see the threads at groups.google.com/d/topic/e-prime/OeiZ00V9SRc<https://urldefense.com/v3/__http://groups.google.com/d/topic/e-prime/OeiZ00V9SRc__;!!HXCxUKc!kW4wT5yhVthr0KL1Mn_anGWItAOWSNG-TfahsGy1S03ZIMgK7RtAsV22PvPzFIVP$>
> , groups.google.com/d/topic/e-prime/6jTtoQ8qENg<https://urldefense.com/v3/__http://groups.google.com/d/topic/e-prime/6jTtoQ8qENg__;!!HXCxUKc!kW4wT5yhVthr0KL1Mn_anGWItAOWSNG-TfahsGy1S03ZIMgK7RtAsV22PoqFNQDS$> , and groups.google.com/d/topic/e-prime/luXrAFWy7Sc<https://urldefense.com/v3/__http://groups.google.com/d/topic/e-prime/luXrAFWy7Sc__;!!HXCxUKc!kW4wT5yhVthr0KL1Mn_anGWItAOWSNG-TfahsGy1S03ZIMgK7RtAsV22PsfF5T1e$> .
>
> -- David McFarlane

Roni Shafir

unread,
Nov 8, 2021, 9:48:50 AM11/8/21
to e-p...@googlegroups.com
Thanks! Yes, I have already changed it to 0, but accidentally sent the previous version.

Thanks for your assistance!
Roni



בתאריך יום ב׳, 8 בנוב׳ 2021 ב-8:51 מאת McFarlane, David <mcfa...@msu.edu>:
--
You received this message because you are subscribed to a topic in the Google Groups "E-Prime" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/e-prime/uyVumilAaMc/unsubscribe.
To unsubscribe from this group and all its topics, send an email to e-prime+u...@googlegroups.com.

McFarlane, David

unread,
Nov 8, 2021, 10:00:02 AM11/8/21
to e-p...@googlegroups.com
Roni,

OK. So did setting PreRelease to 0 fix the problem that you posted earlier?

Thanks,
-- David McFarlane

________________________________________
From: e-p...@googlegroups.com <e-p...@googlegroups.com> on behalf of Roni Shafir <ronis...@gmail.com>

Sent: Monday, November 8, 2021 9:48 AM
To: e-p...@googlegroups.com


Subject: Re: connecting between e-prime and a socket device

Thanks! Yes, I have already changed it to 0, but accidentally sent the previous version.

Thanks for your assistance!
Roni

בתאריך יום ב׳, 8 בנוב׳ 2021 ב-8:51 מאת McFarlane, David <mcfa...@msu.edu<mailto:mcfa...@msu.edu>>:
Roni,

Thank you for stripping this down to a minimal example. That makes it easy to examine. I wish more people would do this.

Your task program behaves exactly as designed. You have some confusion about how PreRelease works. Please read about PreRelease in the documentation that comes with E-Prime. Also, search for "prerelease" in this Group to find threads that discuss this. Or reread the explanation of PreRelease in my first post in this thread. Hint: Try setting PreRelease to 0 on all of your stimulus objects.

-- David McFarlane

________________________________________
From: e-p...@googlegroups.com<mailto:e-p...@googlegroups.com> <e-p...@googlegroups.com<mailto:e-p...@googlegroups.com>> on behalf of Roni Shafir <ronis...@gmail.com<mailto:ronis...@gmail.com>>


Sent: Friday, November 5, 2021 2:34 PM
To: E-Prime
Subject: Re: connecting between e-prime and a socket device

Thank you both!

We're actually still having problems making this work. Just to make sure I'm clear - we want eprime to send triggers to Unity so that Unity can play the VR segments in accordance with the timing defined in e-prime. For instance, we want Unity to display a fixation for 2 seconds at the beginning of each trial. We need inlines that "tell" unity when and for how long to play it.

Now, we moved the task events and we're using inlines before and after each event. We can successfully send triggers but for some reason the duration of the videos is not correct.

I've attached the e-prime file we're working with (basic task that has 2 trials: 2 seconds ITI ---> 3 seconds pain ----> 1 second jitter), as well as the output triggers. For some reason, the duration of the iti is the duration of the jitter, the duration of the pain is that of the ITI, and the duration of the jitter is that of pain. We're obviously missing something here...

Please let me know if you have any suggestions.

Thanks again!
Roni


On Fri, Nov 5, 2021 at 9:54 AM David McFarlane <mcfa...@msu.edu<mailto:mcfa...@msu.edu><mailto:mcfa...@msu.edu<mailto:mcfa...@msu.edu>>> wrote:
Michiel, Yep, I saw "task events" in the third (second?) paragraph and
ran with that, completely overlooking "We use an inline" at the end of
the first paragraph. Thanks for filling in that angle.

Roni, I hope you find something useful in all this :).

-- David McFarlane


On 2021-11-04 Thu 7:20 PM, Spape, Michiel wrote:
> Hi,

> Sorry, I forgot to say the following about more practical considerations when it comes to VR. I've worked quite a bit with VR, E-Prime, and time-sensitive experiments, and from my experience, there's quite a bit of delay between when you want something to be shown on the screen and when it's actually shown. That is, here (internal-journal.frontiersin.org/articles/10.3389/fnhum.2017.00079/full<https://urldefense.com/v3/__http://internal-journal.frontiersin.org/articles/10.3389/fnhum.2017.00079/full__;!!HXCxUKc!kFf44gpxJC8R-j_pkk4wM9qXSJ2oV2-A9hV2xFnizgsW1S8kQ9HZY0TpElpf3k07$><https://urldefense.com/v3/__http://internal-journal.frontiersin.org/articles/10.3389/fnhum.2017.00079/full__;!!HXCxUKc!kW4wT5yhVthr0KL1Mn_anGWItAOWSNG-TfahsGy1S03ZIMgK7RtAsV22PqiVMr-f$> ) we made specific comparisons between VR, a normal screen, and a virtual screen in a virtual replication of our lab, and we had to go through all sorts of hoops to measure the screen latency between com port triggers and visual input. In fact, we used a light sensor, stuck with a bit of gum to the HMD to find out the delay was in the range of 40 ms or so (if memory serves) in VR conditions compared to a delay in a normal Unity application of ca 80 ms. Point being both were quite substantial.

> For more discussion of OnsetTime, OffsetTime, and related matters, please see the threads at groups.google.com/d/topic/e-prime/OeiZ00V9SRc<https://urldefense.com/v3/__http://groups.google.com/d/topic/e-prime/OeiZ00V9SRc__;!!HXCxUKc!kFf44gpxJC8R-j_pkk4wM9qXSJ2oV2-A9hV2xFnizgsW1S8kQ9HZY0TpEj9rZCpE$><https://urldefense.com/v3/__http://groups.google.com/d/topic/e-prime/OeiZ00V9SRc__;!!HXCxUKc!kW4wT5yhVthr0KL1Mn_anGWItAOWSNG-TfahsGy1S03ZIMgK7RtAsV22PvPzFIVP$>
> , groups.google.com/d/topic/e-prime/6jTtoQ8qENg<https://urldefense.com/v3/__http://groups.google.com/d/topic/e-prime/6jTtoQ8qENg__;!!HXCxUKc!kFf44gpxJC8R-j_pkk4wM9qXSJ2oV2-A9hV2xFnizgsW1S8kQ9HZY0TpErh06m1b$><https://urldefense.com/v3/__http://groups.google.com/d/topic/e-prime/6jTtoQ8qENg__;!!HXCxUKc!kW4wT5yhVthr0KL1Mn_anGWItAOWSNG-TfahsGy1S03ZIMgK7RtAsV22PoqFNQDS$> , and groups.google.com/d/topic/e-prime/luXrAFWy7Sc<https://urldefense.com/v3/__http://groups.google.com/d/topic/e-prime/luXrAFWy7Sc__;!!HXCxUKc!kFf44gpxJC8R-j_pkk4wM9qXSJ2oV2-A9hV2xFnizgsW1S8kQ9HZY0TpEirU9WFv$><https://urldefense.com/v3/__http://groups.google.com/d/topic/e-prime/luXrAFWy7Sc__;!!HXCxUKc!kW4wT5yhVthr0KL1Mn_anGWItAOWSNG-TfahsGy1S03ZIMgK7RtAsV22PsfF5T1e$> .
>
> -- David McFarlane


>
>
> On 2021-11-04 Thu 1:17 PM, ronis...@gmail.com<mailto:ronis...@gmail.com><mailto:ronis...@gmail.com<mailto:ronis...@gmail.com>> wrote:
>> Hi,
>>
>> We're trying to send triggers from e-prime to a VR application via a
>> socket devise. Specifically, we want to sent strings at the onset and
>> at the offset of each trial objects. This way we want the VR
>> application to play certain videos according to e-prime's commands. We
>> use an inline before each object:
>>
>> Socket.WriteString "Object_Onset"
>> Socket.WriteString "Object_Offset"
>>
>> We also defined OnsetTime and OffsetTime in the task events properties
>> of each object.
>>
>> We currently see both triggers ("Object_Onset" and "Object_Offset")
>> sent to the socket, but both are sent at the same time - onset of the objects.
>>
>> We would appreciate your help.
>>
>> Thanks!
>> Roni

--
You received this message because you are subscribed to a topic in the Google Groups "E-Prime" group.

To unsubscribe from this topic, visit https://groups.google.com/d/topic/e-prime/uyVumilAaMc/unsubscribe<https://urldefense.com/v3/__https://groups.google.com/d/topic/e-prime/uyVumilAaMc/unsubscribe__;!!HXCxUKc!kFf44gpxJC8R-j_pkk4wM9qXSJ2oV2-A9hV2xFnizgsW1S8kQ9HZY0TpEuslwF66$>.
To unsubscribe from this group and all its topics, send an email to e-prime+u...@googlegroups.com<mailto:e-prime%2Bunsu...@googlegroups.com>.
To view this discussion on the web visit https://groups.google.com/d/msgid/e-prime/DM6PR12MB26689D5CC4ECECE61F649CBC84919%40DM6PR12MB2668.namprd12.prod.outlook.com<https://urldefense.com/v3/__https://groups.google.com/d/msgid/e-prime/DM6PR12MB26689D5CC4ECECE61F649CBC84919*40DM6PR12MB2668.namprd12.prod.outlook.com__;JQ!!HXCxUKc!kFf44gpxJC8R-j_pkk4wM9qXSJ2oV2-A9hV2xFnizgsW1S8kQ9HZY0TpEtcSK8UD$>.

--
You received this message because you are subscribed to the Google Groups "E-Prime" group.
To unsubscribe from this group and stop receiving emails from it, send an email to e-prime+u...@googlegroups.com<mailto:e-prime+u...@googlegroups.com>.
To view this discussion on the web visit https://groups.google.com/d/msgid/e-prime/CALq6LK3vQah0T%2B4dAjov8PTme%2B8tz9gLwq%2B61TMy87i6ziT4yQ%40mail.gmail.com<https://urldefense.com/v3/__https://groups.google.com/d/msgid/e-prime/CALq6LK3vQah0T*2B4dAjov8PTme*2B8tz9gLwq*2B61TMy87i6ziT4yQ*40mail.gmail.com?utm_medium=email&utm_source=footer__;JSUlJQ!!HXCxUKc!kFf44gpxJC8R-j_pkk4wM9qXSJ2oV2-A9hV2xFnizgsW1S8kQ9HZY0TpEupfSZwt$>.

McFarlane, David

unread,
Nov 8, 2021, 10:33:47 AM11/8/21
to e-p...@googlegroups.com
Roni,

Another thing that might help you (or someone else chancing upon this thread) to troubleshoot this: In your InLine code, add a couple lines to log the time of outputting your messages from the E-Prime side. Add this either immediately before or after your Socket.WriteString commands. E.g.,

c.SetAttrib "Socket.Mssg", "ITI_ST"
c.SetAttrib "Socket.Time", Clock.Read
Socket.WriteString "ITI_ST"

This will add two columns to the .edat2 file that log the message type & time from E-Prime. You could then compare this to the results in your external equipment.

-- David McFarlane

________________________________________
From: e-p...@googlegroups.com <e-p...@googlegroups.com> on behalf of McFarlane, David <mcfa...@msu.edu>
Sent: Monday, November 8, 2021 9:59 AM

Roni,

Thanks,
-- David McFarlane

-- David McFarlane

Thank you both!

Thanks again!
Roni

-- David McFarlane

To unsubscribe from this topic, visit https://urldefense.com/v3/__https://groups.google.com/d/topic/e-prime/uyVumilAaMc/unsubscribe__;!!HXCxUKc!kPvR5du1WbqIMY3Vy3VpGn7XmZPCTlmN711BAFLFc7hXA5Ii3EZUMJmQtHvBZlSY$ <https://urldefense.com/v3/__https://groups.google.com/d/topic/e-prime/uyVumilAaMc/unsubscribe__;!!HXCxUKc!kFf44gpxJC8R-j_pkk4wM9qXSJ2oV2-A9hV2xFnizgsW1S8kQ9HZY0TpEuslwF66$>.


To unsubscribe from this group and all its topics, send an email to e-prime+u...@googlegroups.com<mailto:e-prime%2Bunsu...@googlegroups.com>.

To view this discussion on the web visit https://urldefense.com/v3/__https://groups.google.com/d/msgid/e-prime/DM6PR12MB26689D5CC4ECECE61F649CBC84919*40DM6PR12MB2668.namprd12.prod.outlook.com__;JQ!!HXCxUKc!kPvR5du1WbqIMY3Vy3VpGn7XmZPCTlmN711BAFLFc7hXA5Ii3EZUMJmQtJlaN_a6$ <https://urldefense.com/v3/__https://groups.google.com/d/msgid/e-prime/DM6PR12MB26689D5CC4ECECE61F649CBC84919*40DM6PR12MB2668.namprd12.prod.outlook.com__;JQ!!HXCxUKc!kFf44gpxJC8R-j_pkk4wM9qXSJ2oV2-A9hV2xFnizgsW1S8kQ9HZY0TpEtcSK8UD$>.

--
You received this message because you are subscribed to the Google Groups "E-Prime" group.
To unsubscribe from this group and stop receiving emails from it, send an email to e-prime+u...@googlegroups.com<mailto:e-prime+u...@googlegroups.com>.

To view this discussion on the web visit https://urldefense.com/v3/__https://groups.google.com/d/msgid/e-prime/CALq6LK3vQah0T*2B4dAjov8PTme*2B8tz9gLwq*2B61TMy87i6ziT4yQ*40mail.gmail.com__;JSUlJQ!!HXCxUKc!kPvR5du1WbqIMY3Vy3VpGn7XmZPCTlmN711BAFLFc7hXA5Ii3EZUMJmQtJFigRGF$ <https://urldefense.com/v3/__https://groups.google.com/d/msgid/e-prime/CALq6LK3vQah0T*2B4dAjov8PTme*2B8tz9gLwq*2B61TMy87i6ziT4yQ*40mail.gmail.com?utm_medium=email&utm_source=footer__;JSUlJQ!!HXCxUKc!kFf44gpxJC8R-j_pkk4wM9qXSJ2oV2-A9hV2xFnizgsW1S8kQ9HZY0TpEupfSZwt$>.

--
You received this message because you are subscribed to the Google Groups "E-Prime" group.

To unsubscribe from this group and stop receiving emails from it, send an email to e-prime+u...@googlegroups.com.
To view this discussion on the web visit https://urldefense.com/v3/__https://groups.google.com/d/msgid/e-prime/DM6PR12MB26689A45FD5F834CF327DB6084919*40DM6PR12MB2668.namprd12.prod.outlook.com__;JQ!!HXCxUKc!kPvR5du1WbqIMY3Vy3VpGn7XmZPCTlmN711BAFLFc7hXA5Ii3EZUMJmQtEggP8dk$ .

Roni Shafir

unread,
Nov 8, 2021, 12:09:58 PM11/8/21
to e-p...@googlegroups.com
Thanks! That’s very helpful.

When I check the triggers output-file, it actually looks like PreRelease (same as duration) creates a smaller delay (last two trials in the below pic), relative to the 0 option (first two trials).

Roni

Thanks 



בתאריך יום ב׳, 8 בנוב׳ 2021 ב-10:33 מאת McFarlane, David <mcfa...@msu.edu>:
To unsubscribe from this topic, visit https://groups.google.com/d/topic/e-prime/uyVumilAaMc/unsubscribe.
To unsubscribe from this group and all its topics, send an email to e-prime+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/e-prime/DM6PR12MB26682C7A2A33249C12B5C42384919%40DM6PR12MB2668.namprd12.prod.outlook.com.

David McFarlane

unread,
Nov 11, 2021, 1:10:39 PM11/11/21
to e-p...@googlegroups.com
Roni and I discussed this further outside the Group, and I think that
some things deserve an update here.

By "delay", Roni actually means "duration error". And by smaller
duration error, Roni notes that stimulus durations reported by the
triggers output file look more like nice round numbers when using "(same
as duration)". Unfortunately, the durations reported there do not fit
the stimulus duration settings in E-Prime: specified durations of the
three objects are 2000, 3000, & 1000 ms, while the triggers output file
shows durations of about 1000, 2000, & 3000 (i.e., reported durations
are rotated). So when using "(same as duration)" the markers do not
occur at the right times.

Using PreRelease = 0 does create markers more or less at the right time,
but with tens of ms of delay from execution of the Socket.WriteString
command to the OnsetTime of the associated stimulus object. Up to 17 ms
of that could result simply from waiting for a screen refresh. Beyond
that, I wonder if the Socket.WriteString command itself takes up a lot
of time. This needs to be explored.

-- David McFarlane


On 2021-11-08 Mon 12:09 PM, Roni Shafir wrote:
> Thanks! That’s very helpful.
>
> When I check the triggers output-file, it actually looks like PreRelease
> (same as duration) creates a smaller delay (last two trials in the below
> pic), relative to the 0 option (first two trials).
>
> Roni
>
> Thanks
>
>
>
> בתאריך יום ב׳, 8 בנוב׳ 2021 ב-10:33 מאת McFarlane, David
> <mcfa...@msu.edu <mailto:mcfa...@msu.edu>>:
>
> Roni,
>
> Another thing that might help you (or someone else chancing upon
> this thread) to troubleshoot this:  In your InLine code, add a
> couple lines to log the time of outputting your messages from the
> E-Prime side.  Add this either immediately before or after your
> Socket.WriteString commands.  E.g.,
>
>     c.SetAttrib "Socket.Mssg", "ITI_ST"
>     c.SetAttrib "Socket.Time", Clock.Read
>     Socket.WriteString "ITI_ST"
>
> This will add two columns to the .edat2 file that log the message
> type & time from E-Prime.  You could then compare this to the
> results in your external equipment.
>
> -- David McFarlane
>
> ________________________________________
> From: e-p...@googlegroups.com <mailto:e-p...@googlegroups.com>
> <e-p...@googlegroups.com <mailto:e-p...@googlegroups.com>> on
> behalf of McFarlane, David <mcfa...@msu.edu <mailto:mcfa...@msu.edu>>
> Sent: Monday, November 8, 2021 9:59 AM
> To: e-p...@googlegroups.com <mailto:e-p...@googlegroups.com>
> Subject: Re: connecting between e-prime and a socket device
>
> Roni,
>
> OK.  So did setting PreRelease to 0 fix the problem that you posted
> earlier?
>
> Thanks,
> -- David McFarlane
>
> ________________________________________
> From: e-p...@googlegroups.com <mailto:e-p...@googlegroups.com>
> <e-p...@googlegroups.com <mailto:e-p...@googlegroups.com>> on
> behalf of Roni Shafir <ronis...@gmail.com
> <mailto:ronis...@gmail.com>>
> Sent: Monday, November 8, 2021 9:48 AM
> To: e-p...@googlegroups.com <mailto:e-p...@googlegroups.com>
> Subject: Re: connecting between e-prime and a socket device
>
> Thanks! Yes, I have already changed it to 0, but accidentally sent
> the previous version.
>
> Thanks for your assistance!
> Roni
>
>
>
> בתאריך יום ב׳, 8 בנוב׳ 2021 ב-8:51 מאת McFarlane, David
> <mcfa...@msu.edu <mailto:mcfa...@msu.edu><mailto:mcfa...@msu.edu
> <mailto:mcfa...@msu.edu>>>:
> Roni,
>
> Thank you for stripping this down to a minimal example.  That makes
> it easy to examine.  I wish more people would do this.
>
> Your task program behaves exactly as designed.  You have some
> confusion about how PreRelease works.  Please read about PreRelease
> in the documentation that comes with E-Prime.  Also, search for
> "prerelease" in this Group to find threads that discuss this. Or
> reread the explanation of PreRelease in my first post in this
> thread.  Hint:  Try setting PreRelease to 0 on all of your stimulus
> objects.
>
> -- David McFarlane
>
> ________________________________________
> From: e-p...@googlegroups.com
> <mailto:e-p...@googlegroups.com>>> on behalf of Roni Shafir
> <ronis...@gmail.com
> <mailto:ronis...@gmail.com><mailto:ronis...@gmail.com
> <mailto:mcfa...@msu.edu>><mailto:mcfa...@msu.edu
> <mailto:mcfa...@msu.edu><mailto:mcfa...@msu.edu
> <mailto:mcfa...@msu.edu>>>> wrote:
> Michiel, Yep, I saw "task events" in the third (second?) paragraph and
> ran with that, completely overlooking "We use an inline" at the end of
> the first paragraph.  Thanks for filling in that angle.
>
> Roni, I hope you find something useful in all this :).
>
> -- David McFarlane
>
>
> On 2021-11-04 Thu 7:20 PM, Spape, Michiel wrote:
> > Hi,
> > Sorry, I forgot to say the following about more practical
> considerations when it comes to VR. I've worked quite a bit with VR,
> E-Prime, and time-sensitive experiments, and from my experience,
> there's quite a bit of delay between when you want something to be
> shown on the screen and when it's actually shown. That is, here
> (internal-journal.frontiersin.org/articles/10.3389/fnhum.2017.00079/full
> <https://urldefense.com/v3/__http://internal-journal.frontiersin.org/articles/10.3389/fnhum.2017.00079/full__;!!HXCxUKc!l-NPHbc-bFRov5krwi133uqxdz1DXpLjiq7NBs5wI-ExXADcm9XSAkzUj-S4e9dm$><https://urldefense.com/v3/__http://internal-journal.frontiersin.org/articles/10.3389/fnhum.2017.00079/full__;!!HXCxUKc!kFf44gpxJC8R-j_pkk4wM9qXSJ2oV2-A9hV2xFnizgsW1S8kQ9HZY0TpElpf3k07$
> <mailto:e-p...@googlegroups.com>><mailto:e-p...@googlegroups.com
> <mailto:e-p...@googlegroups.com><mailto:e-p...@googlegroups.com
> <mailto:e-p...@googlegroups.com>><mailto:e-p...@googlegroups.com
> <mailto:e-p...@googlegroups.com><mailto:e-p...@googlegroups.com
> <https://urldefense.com/v3/__http://groups.google.com/d/topic/e-prime/OeiZ00V9SRc__;!!HXCxUKc!l-NPHbc-bFRov5krwi133uqxdz1DXpLjiq7NBs5wI-ExXADcm9XSAkzUj2kZ4AJ1$><https://urldefense.com/v3/__http://groups.google.com/d/topic/e-prime/OeiZ00V9SRc__;!!HXCxUKc!kFf44gpxJC8R-j_pkk4wM9qXSJ2oV2-A9hV2xFnizgsW1S8kQ9HZY0TpEj9rZCpE$
> <https://urldefense.com/v3/__http://groups.google.com/d/topic/e-prime/6jTtoQ8qENg__;!!HXCxUKc!l-NPHbc-bFRov5krwi133uqxdz1DXpLjiq7NBs5wI-ExXADcm9XSAkzUj3i4NETt$><https://urldefense.com/v3/__http://groups.google.com/d/topic/e-prime/6jTtoQ8qENg__;!!HXCxUKc!kFf44gpxJC8R-j_pkk4wM9qXSJ2oV2-A9hV2xFnizgsW1S8kQ9HZY0TpErh06m1b$
> <https://urldefense.com/v3/__http://groups.google.com/d/topic/e-prime/luXrAFWy7Sc__;!!HXCxUKc!l-NPHbc-bFRov5krwi133uqxdz1DXpLjiq7NBs5wI-ExXADcm9XSAkzUjz77mxG9$><https://urldefense.com/v3/__http://groups.google.com/d/topic/e-prime/luXrAFWy7Sc__;!!HXCxUKc!kFf44gpxJC8R-j_pkk4wM9qXSJ2oV2-A9hV2xFnizgsW1S8kQ9HZY0TpEirU9WFv$
> <mailto:ronis...@gmail.com>><mailto:ronis...@gmail.com
Reply all
Reply to author
Forward
0 new messages