Several flickering tasks run simultaneously

[dkmcf]

Glad you got it to work so easily!  And your report of success made me
realize the error of my excessive computations -- of course you did
not need to continue the List out to the least-common-multiple of your
period times, you only needed to cover the few seconds of the
stimulus, which, after adjusting the period times a bit, is quite
manageable.  Kudos to you & Mich together.

-- David McFarlane, Professional Faultfinder


On Jul 7, 8:11 pm, pati-confidence <pati.confide... at gmail.com> wrote:
> Thank you for your so detailed and valuable relies.
> I have implemented the required task by the use of the Slide, with four
> targets flickering in 10Hz, 11Hz, 12Hz and 15Hz respectively, which is much
> easier than flickering in 7.5Hz, 8.6Hz, 10Hz, 12Hz.
> And I will attempt your method later.
> Thank you very much!
>
> guobing Wu
>
>
>
>
>
>
>
> On Fri, Jul 8, 2011 at 3:08 AM, David McFarlane <mcfar... at msu.edu> wrote:
> > Ah, checked my own E-Prime FAQ, and here is the link of where I have
> > addressed this kind of question before:http://groups.google.com/**
> > group/e-prime/browse_thread/**thread/fda0b9bbe3a149c3<http://groups.google.com/group/e-prime/browse_thread/thread/fda0b9bbe...>
>
> > -- David McFarlane, Professional Faultfinder
> > (Now next time someone asks this, I will try to direct them to the thread
> > from today :))
>
> > At 7/7/2011 03:03 PM Thursday, David McFarlane wrote:
>
> >> Mich beat me to the punch, and with the answer that I would have given at
> >> first.  And Mich adds a crucial concern that I would have overlooked, namely
> >> that your chosen flicker times only work if they are each commensurate with
> >> your display refresh rate, which they probably are not (your chosen flicker
> >> frequencies translate to periods of 83.3, 100, 116.3, and 113.3 ms,
> >> respectively, and you would have to find a common divisor to all of those in
> >> the range of roughly 8.3 to 16, good luck!).  But I can't resist weighing in
> >> further...
>
> >> Setting aside your incommensurate flicker rates, can E-Prime do this?
> >>  Well (as Mich already said), yes, in principle; but in practice, for this
> >> particular task you might be far better off using something like
> >> Presentation, or MATLAB with the Psychophysics Toolkit (my own first choice
> >> for your task).  You would like a toolset that includes pre-made objects
> >> that can flicker themselves at specified rates, and then set those running.
> >>  AFAIK, EP has no such facility, but maybe Presentation or MATLAB or
> >> Psychopy do, and then Bob's your uncle!
>
> >> Next, you could try Mich's fine suggestion, but once again I fear that
> >> incommensurability will raise its ugly head.  Now you not only need a common
> >> divisor, but you need a List that contains the pattern of on-off images for
> >> each time point until the entire temporal pattern repeats, and that will not
> >> happen until you reach the least-common-multiple of the individual period
> >> times, and in your case that will be greater than, say, 83.3 * 113.3 = 9.5
> >> s, and perhaps as great as 83.3 * 100 * 116.3 * 113.3 = 30.7 h.  Yikes!  Of
> >> course, if you are not wedded to these period times, then you might adust
> >> them to more workable values (there's a nice academic exercise for you).
>
> >> But I said E-Prime could do this, and here's how.  It would require some
> >> intricate code, the same way that you could do it in any full-featured
> >> programming language, such as C or C++ or even JavaScript, and I have done
> >> things like this myself in C.  You would need to contruct your own "event
> >> loop" (do a search of the Group or the Forum on that phrase to see where I
> >> have discussed this before).  In short, you create an array that holds the
> >> upcoming transition time for each object (in this case, your four flickering
> >> targets).  Each time through the loop it just checks each of these times
> >> against the current clock time, and when any one reaches its next transition
> >> time then the loop updates that target and adjuts its transition time for
> >> the next one.  Your loop just does that for the duration of the display.
> >>  Here is some pseudo-code for that (using my own odd mixture of C-like and
> >> other notation):
>
> >> while( presentation_ongoing )
> >>    for( i = 1 to nTargets )
> >>        if( Clock.Read >= target[i].tNext )
> >>            target[i].toggle
> >>            target[i].tNext = target[i].tNext + target[i].tPeriod
>
> >> Of course, you also have to initialize .tPeriod and .tNext for each
> >> target, and I left out the mechanics of how to implement anything like a
> >> .toggle method to redraw a target between its two states, but I leave those
> >> as exercises.
>
> >> -- David McFarlane, Professional Faultfinder
>
> >> (P.s.  For those who know more C-like notation, the pseudo-code above
> >> could be more nicely written as
>
> >> while( presentation_ongoing )
> >>    for( i = 1 to nTargets )
> >>        if( Clock.Read >= target[i].tNext )
> >>            target[i].toggle
> >>            target[i].tNext += target[i].tPeriod
>
> >> Isnt' that nice?)
>
> >> At 7/6/2011 05:12 AM Wednesday, Michiel Spape wrote:
>
> >>> Oh, wait, simultaneous tasks, you say?
> >>> I think there are a few ways of handling this...
> >>> How about you make one slide with your four targets. These are four text
> >>> "sub objects". Each target has a colour: white (as in, off, since the
> >>> background is white), or black. See first how you can make them black or
> >>> white (it's the background colour thing). Then, set each to [Target1Colour],
> >>> [Target2Colour], [Target3Colour] and [Target4Colour] instead. The slide has
> >>> a duration of slightly below your maximum refresh rate (i.e. 15 ms if your
> >>> monitor runs at 60 Hz), and onset sync is on.
> >>> Make a list, sequential selection, 1 procedure, and set Exit after to 1
> >>> sec (i.e., it repeats for one second). Drag the slide you just made to the
> >>> one procedure.
> >>> Add 4 procedures to the list: Target1Colour, Target2Colour,
> >>> Target3Colour, Target4Colour. Think of the list as one second, and add
> >>> levels accordingly: if your monitor runs at 60 Hz, there should be at least
> >>> 60 levels. Find out, at each level, which of the targets is black. For
> >>> instance, your second target, flickering at 10 Hz, should be black at the
> >>> first level (time = 0 ms), 7th level (time = 100 ms), 13th level (time = 200
> >>> ms) and so on, but white at level 2-6, and so on.
>
> >>> Well, voila, there you go, it should now flicker. Of course, nothing is
> >>> randomised, but it should work, and I think you might be able to take it
> >>> from there. Also, no code yet.
> >>> Best,
> >>> Michiel
>
> >>> Michiel Spapé
> >>> Research Fellow
> >>> Perception & Action group
> >>> University of Nottingham
> >>> School of Psychology
> >>>www.cognitology.eu
>
> >>> -----Original Message-----
> >>> From: e-prime at googlegroups.com [mailto:e-prime at googlegroups.**com<e-prime at googlegroups.com>]
> >>> On Behalf Of pati-confidence
> >>> Sent: 06 July 2011 06:17
> >>> To: E-Prime
> >>> Subject: Several flickering tasks run simultaneously
>
> >>> I want to build a BCI system, which presents four targets on LCD
> >>> screen, with flickering frequencies of 12Hz, 10Hz, 8.6Hz and 7.5Hz.
> >>> respectively.
>
> >>> And the four targets are flickering simultaneously.
>
> >>> Can E-prime achieve the goal?
>
> >>> Any tips will be appreciate.  Thank you.

-- 
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.