milliseconds timing & subliminal stimuli

[Phil Davis]

Mark Smith wrote:
> David, you may well have been down this route, but the following little 
> experiment I found quite interesting:
> 
> on mouseUp
>   put the millisecs into t0
>   show img "alex"
>   unlock screen
>   put the millisecs into t1
>   repeat
>     if the millisecs >= t1 + 30 then
>       hide img "alex"
>       unlock screen
>       put the millisecs into t2
>       exit repeat
>     end if
>   end repeat
> 
>   put t1 - t0 && t2 - t0 && t2 - t1
> end mouseUp
> 
> The 'unlock screen' meant that I always actually saw the image (I 
> believe it forces a screen refresh), and the repeat loop guarantees (I 
> think) that the image is visible for at least 30 ms.
> 
> The timing measurements were (on my 1.5Ghz G4 laptop):
> 
> t1 - t0  9 to 20
> t2 - t0 45 to 60
> t2 - t1 reliably 36 +- 1
> 
> No idea if this is helpful, but I thought I'd throw it in...


Hi Mark, David,

This is interesting. But even with 'unlock screen', wouldn't Rev be 
subject to screen refresh cycles for displaying things? To me, 
refreshing the screen on the very next cycle is like catching a bus - 
you can catch the very next bus, but you have to wait until it arrives 
before doing so. (sorry - simple analogies and metaphors are the only 
ways I can understand some things!)

Seems to me there's a hardware-induced lag time here that can't be 
eliminated or controlled from scripting. The best we can hope for is 
accurately measuring the lag so we can compensate for it in scripting. 
At least that's what I'm shooting for.

I would like to find a way to accurately pinpoint the appearance time 
of objects without using an external.

I've experimented with this approach:
- position the mouse over the loc of a (still hidden) graphic
- show a solid-color (255,0,0) graphic
- put the milliseconds into x
- wait until the mouseColor = "255,0,0"
- put the milliseconds - x

If the mouse keeps moving while waiting for the object to appear, this 
approach seems to work - at least the timings it yields are plausible, 
in the 10 to 25 msec range. But the mouse has to be moving.

To determine what it was about mouse movement that made it 
[apparently] work, I tried a couple of things:
- bombard the object with 'mouseMove' messages from
   shortly before 'show' to some time after 'show'
- script some mouse movement throughout the 'show' period,
   staying within 2 pixels of the loc of the object

Neither of these efforts yielded the same kind of timings I got when 
manually moving the mouse. Instead I get 250 msecs or so.

Any other ideas?

Thanks -
Phil Davis



> 
> Best,
> 
> Mark
> 
> On 27 Apr 2007, at 13:10, David Glasgow wrote:
> 
>> Thanks to all who previously chipped in on this topic.  I have been 
>> doing a bit of research, using the following script:
>> +++++++++++++++++++++
>>
>> on mouseUp
>>
>>   --  scrollbars to fiddle with the various times
>>
>>   --  duration of the image of the person
>>   get the thumbpos of scrollbar "milliseconds"
>>
>> --  duration of the gap between picture and mask
>>   put the thumbpos of scrollbar "gap" into tgap
>>
>> --  this is the duration of the mask
>>   put the thumbpos of scrollbar "show" into tshow
>>
>> --  present a submarine style cross to focus attention
>>   show group "targit"
>>   wait 1000 milliseconds
>>   hide group "targit"
>>
>>   put the milliseconds into tstart
>>
>>   show image "adf03"
>>   wait it milliseconds
>>   hide image "adf03"
>>
>>   put the milliseconds - tstart & return after field "actualtime"
>>
>>   wait tgap milliseconds
>>   show grc "rectangle"
>>   wait tshow milliseconds
>>   hide grc "rectangle"
>> end mouseUp.
>>
>> ++++++++++++++++++++++
>>
>> What happens is that a crosshair style target appears for 1 sec.  Then 
>> a picture of a person appears for 'it' milliseconds, then there is a 
>> gap of tgap milliseconds, then a mask appears for tshow milliseconds.  
>> The mask is a rect filled with a pattern.  Its purpose is a technical 
>> one, called backward masking (no, not like on heavy metal records).  
>> If an image appears briefly followed by the mask, the amount of 
>> conscious psychological processing permitted by the person viewing it 
>> can be truncated.  Images which would be recognisable at a given 
>> display duration are rendered invisible but still processed 
>> psychologically.  Don't ask how, it just works.  (If your really want 
>> to know, take a look here --> http://www.ac-psych.org/?id=3 )
>>
>> You can above see that field 'actualtime' accumulates the duration of 
>> the display of the picture of the person (plus the time taken to do 
>> the timing) over successive runs.    With the duration of the person 
>> image set at 30 ms, (gap = 40 ms and mask = 160 ms), I shouldn't be 
>> able to see the image of the person, at least not conciously, but I can.
>>
>> Now I expected to get variable effects in appearance, because I am 
>> testing on a MacBook, so my guess  is that the LCD just won't keep up 
>> with these rapid display changes. What I was planning to do was shift 
>> the test stack to a CRT box, and set the refresh rate to 100Hz (in 
>> fact I think it goes to 138Hz).  In the literature, I can see that 
>> images can be displayed for a single cycle at 60Hz, and the effect can 
>> work).  What surprised me on the MacBook is the recorded variability 
>> of the durations, irrespective of the fact that I can see the person 
>> when I shouldn't be able to.  The mean measured display time (set as 
>> above) is 38 ms, min 32 and max 50, Standard Deviation = 4.46 (over 30 
>> trials).  I can slide the scrollbar to such a short duration when I 
>> can't see the image of the person, but of course I can't know whether 
>> this is because the backward masking is working, or because the image 
>> really isn't appearing!
>>
>> One of the things which occurred to me is that I could adapt the test 
>> script above to do a kind of calibration routine, so that the 
>> milliseconds is set to fall in the middle of the distribution of 
>> actual durations, so that some will be  a little shorter than 30ms, 
>> and others a little more.
>>
>> I would welcome any thoughts or comments on what I am doing, and 
>> suggestions for doing it better.
>>
>> Best Wishes,
>>
>> David Glasgow