Millisecond Forums

Hi Jonathan,

I've tested out your script and looked it over, and I'm not seeing any perceptible delays either.

A couple of questions/suggestions to help us narrow this down:

1) What kind of computer are you running, and with which version of Windows?
2) Are the graphics drivers on your computer up to date?
3) Are you able to reproduce this problem on any other computers that aren't configured exactly like yours?

-Sean

I'm definitely not seeing any such pronounced delays (~1000ms) with the script you attached -- off/on transitions are virtually instantaneous (as one would expect). As for diagnostics, you can set /audit=true in your script's element. That'll give you an additional file containing detailed stimulus timing info. Give that a try, perhaps that'll give some leads.

Regards,

~Dave

P.S.: Sorry for the delayed reply, the forum was partially botched and didn't accept any replies to this thread.

Hi Dave,

The "delay" I'm speaking of hasn't been recorded by any other method - I'm just going by my own perception while running the task. When I remove the background image, the task proceeds as it should - i.e. I can't detect any delay between pressing the central button and one of the outer lights lighting up. However, when I run the version I attached, there is a very noticeable delay - I would estimate it to be almost one second - between pressing the button and illumination. This is especially bizarre because it didn't happen in earlier versions of the task, it only came about after I finished the coding on my home computer (most of it had been done in the office).

If there's anything I can do to help document this problem, i.e. run some sort of Inquisit doiagnostic, please let me know.

Thanks

Jon

I've tried with the same version. Still, I'm not seeing any issue. Which leads me to ask: How do you detect that delay in the first place? A single-frame lag should be virtually impossible to detect perceptually. So I assume you've devised some other method and have taken some measurements. Would you kindly share that method and data? That might help to track the problem down.

Thanks,
~Dave

Hi Dave,

That's really strange. I reinstalled Inquisit yesterday with intention of eliminating that possibility. I'm currently running version 3.0.6.0 with a build date of Jan 18 2012. As far as I can see, everything is up to date.

Could there be any other reasons?

Thanks

Jon

Jon,

I'm seeing no such delays with your script, doesn't matter whether I remove the machine background image from the trials or not. Is your Inquisit installation up to date or are you by chance running an outdated build?

Hi Dave, Sean


I stumbled across this thread while trying to solve a delay/lag issue I'm having with a script I've developed.


I've attached the script (archived as a .rar file with associated files) to this post. Basically the task is to turn off a bunch of lights as quickly as possible. After each light has been turned off by clicking on it, the participant must press a central button to commence the next trial (i.e. turn on the next light to be extinguished).


The problem is that there is a delay of a fraction of a second between each trial (e.g. the next light doesn't turn on immediately after clicking the central button). Since I'm trying to get the participants to do this as quickly as possible this is highly problematic.


I have a feeling the problem is to do with the stimuli. Each of the lights, and also the central button, are represented by two .jpg files - one corresponding to the on state and one corresponding to the off state. There is also a background .jpg file that makes the whole task look like it is being carried out on an actual machine (machine.jpg or machinewin.jpg). All the other stimuli are superimposed on top of this.

After reading through this thread, I've tried messing with the erase and post trial pause commands to try and eliminate the delay but to no avail. Please note that the default for all stimuli currently is erase=false, so erasing shouldn't be the problem.


Strange Observation No. 1: I HAVE managed to eliminate the delay by removing the background stimulus image (i.e. I removed it from /stimulusframes in all the trials. Once I do this, there is no delay. This seems very odd though, as the .jpg files are so small I can't imagine it's overworking my computer's memory.


Strange Observation No. 2: If I DO set all the stimuli to erase=true, the time taken to erase all the stimuli at the end of the trial does seem to match closely with the delay I'm experiencing. This may or may not be a coincidence.


Any ideas? I could always just remove the background image and make the task less pretty/realistic-looking, but I figure there must be a way to solve this.


NB: I have tried on multiple computers and the problem persists.


Hope you can help,


Jon

Ha! Huge thanks for digging into and solving the timing lag mystery, Sean! Any idea why it only showed on some systems but not on others, though? Speaking of bugs, I had discovered a couple of other, minor potential bugs while coding the timing debug / testing script. Since these are scattered all over this thread, I'll summarize them here:

- The 'stimulusonset' property always returns empty.

- The 'recorddata' switch appears to be unfunctional at the <expt> level. This may be only be the case when <data> element is set to 'separatefiles=true'.

Cheers and thanks again,

~Dave

P.S.: I second Matt's sentiment about adding a timing test script to the Task Library. Feel free to use the script I have posted to this thread as a starting point. @Matt: Maybe you could brush up on the script (add a few more features, e.g. a count of deviating trial durations, etc., and comments) and submit it for publication in the Task Library? Apart from 'giving back to the community', that would make a nice, little exercise in using Inquisit's advanced features for you...

Ok, I've dug more deeply into this, and identified the cause of the extra lags. Basically, the lags are equal to two retrace intervals of the monitors (as Dave had earlier surmised).

The first interval is because when Inquisit prepares to write the stimuli to the screen, it stalls until the beginning of a retrace interval. This can take up to 1 interval in duration and is currently added to the total duration of the trial, assuming no postrialpause is set.

The 2nd interval lag was simply a bug as Inquisit mistakenly waited until the next interval began before advancing.

Both of these lags were consumed into the posttrialpause, so they wouldn't affect timing if that command is set. I will hopefully have a fix ready for both shortly.

-Sean

Dave,

Sorry for being unclear - what I meant was b), i.e. the debugging script is showing lags of about 30ms on each trial, despite all the optimisations.

Cheers,

M.