wait to collect response
Matt Paffel
mpaffel at gmail.com
Fri Oct 29 18:31:36 UTC 2010
Thanks for the response David and you are absolutely correct, this
setup does not have the sound terminate. The original files contained
a few milliseconds of negative space after the sustain modifier drops
off. Simply editing the sound files to remove this space remedied the
need for the sound to terminate as the effect quickly drops to 0 after
the chord has played which in turn makes it relatively inaudible
through the fixation period between trials.
On Oct 28, 2:01 pm, David McFarlane <mcfar... at msu.edu> wrote:
> Matt,
>
> Oh, and I don't see how any of these solutions
> terminate the sound playback for a response past
> the 4800 ms (as specified in the opeining post),
> other than having the playback of the next sound
> terminate the playback of the previous
> sound. But perhaps I am just missing something. How did you get that to work?
>
> -- David McFarlane, Professional Faultfinder
>
>
>
> David McFarlane wrote:
> >Matt,
>
> >Hmm, so if the subject is "trigger-happy" and
> >submits any responses before the 4800 ms mark,
> >you want the program to ignore those and accept
> >only their first response past the 4800 ms
> >mark? E.g., it's OK if the subject responds
> >once a second over the first 4800 ms (i.e., four
> >times) and then responds once more after the
> >4800 ms mark, and the program accepts only the fifth response?
>
> >I had misread your earlier post and thought that
> >you meant to collect one response only any time
> >during the playback of the sound (e.g., any time
> >during the full 5500 ms), while making sure that
> >the sound played through at least 4800 ms and
> >thereafter terminated upon any response
> >(including any response detected earlier), and
> >was prepared to write up solutions for that
> >situation (all involving some degree of inline
> >code). But if you really mean to ignore
> >premature responses, then, for the record, you
> >don't really need the initial TextDisplay nor
> >the intervening Wait object. You could
> >accomplish the same end simply with something like
>
> >StimSound
> >RespWait
>
> >where StimSound presents the sound with Duration
> >of, e.g., 4800 (or, if this varies from stimulus
> >to stimulus, set using an an attribute
> >reference) and Stop After = No, and RespWait is
> >a Wait object with Duration and input mask set
> >as needed to collect the response made after the 4800 ms mark.
>
> >-- David McFarlane, Professional Faultfinder
>
> >>Hey Mich, Thanks for the input.
>
> >>I was actually able to remedy this by using a couple of different
> >>objects.
> >>First, I have a TextDisplay, duration = 0
> >>Then, the SoundOut object, duration = 0 and stop after is set to no.
> >>After that I have a wait object duration set to 4800ms.
> >>Lastly, I have another TextDisplay to collect the response made at the
> >>4800 mark.
> >>It seems to work out pretty slick.
>
> >>Thanks again,
>
> >>Matt
>
> >>On Oct 28, 3:41 am, Michiel Spape <Michiel.Sp... at nottingham.ac.uk>
> >>wrote:
> >> > Hi,
> >> > If I'm understanding all of this correctly,
> >> I think the simplest way to do this would be
> >> to disconnect the audio stimulus and the event at 4800.
> >> > i.e.:
> >> > 0 ms: Sound starts playing
> >> (SoundBuffer.Play). Also, log onset of sound
> >> (e.g. c.SetAttrib "SoundOnsetTime", Clock.read)
> >> > [no response capturing]
> >> > 4800 ms: some kind of marker (say, an
> >> invisible TextDisplay1) end action to terminate
> >> > Between 4800 and 5500 ms: at termination of TextDisplay1:
> >> > If TextDisplay1.RESP <> "" then
> >> > SoundBuffer.Stop 'kills sound
> >> > c.SetAttrib "RT", TextDisplay.RTTime
> >> - c.GetAttrib("SoundOnsetTime") 'saves RT based on soundbuffer onset time.
> >> > end If
>
> >> > So, in essence, I'd say that the easiest way
> >> to "hold off on collecting a response" would,
> >> essentially, be NOT to collect a response before the time.
> >> > Best,
> >> > Mich
>
> >> > Michiel Spapé
> >> > Research Fellow
> >> > Perception & Action group
> >> > University of Nottingham
> >> > School of Psychologywww.cognitology.eu
>
> >> > -----Original Message-----
> >> > From: e-prime at googlegroups.com
> >> [mailto:e-prime at googlegroups.com] On Behalf Of Matt Paffel
> >> > Sent: 27 October 2010 17:06
> >> > To: E-Prime
> >> > Subject: wait to collect response
>
> >> > Hello,
>
> >> > I have an experiment that runs some audio files and I'm having an
> >> > issue somewhat similar to what was discussed in this post:
>
> >> >http://groups.google.com/group/e-prime/browse_thread/thread/9d6274c8e...
>
> >> > The experiment that I have runs audio files that are approximately
> >> > 5500ms in length and the event that a participant needs to respond to
> >> > occurs at 4800ms. I wrote some script to adjust the real reaction time
> >> > from the RT of the object which works fine.
>
> >> > I also have the audio object set to terminate after a participant has
> >> > made a response thus moving them to the next trial.
>
> >> > The issue with the program is that if a participant responds prior to
> >> > the 4800 mark, the program jumps to the next trial. Turning the
> >> > objects end action to "none" doesn't help because if a participant
> >> > responds prior to the 4800 mark, the RT collected is not for the event
> >> > under study.
>
> >> > My question is, is there a way to hold off on collecting a response
> >> > for an allotted amount of time to an object?
>
> >--
> >You received this message because you are
> >subscribed to the Google Groups "E-Prime" group.
> >To post to this group, send email to e-prime at googlegroups.com.
> >To unsubscribe from this group, send email to
> >e-prime+unsubscribe at googlegroups.com.
> >For more options, visit this group at
> >http://groups.google.com/group/e-prime?hl=en.- Hide quoted text -
>
> - Show quoted text -
--
You received this message because you are subscribed to the Google Groups "E-Prime" group.
To post to this group, send email to e-prime at googlegroups.com.
To unsubscribe from this group, send email to e-prime+unsubscribe at googlegroups.com.
For more options, visit this group at http://groups.google.com/group/e-prime?hl=en.
More information about the Eprime
mailing list