can't locate local ip and startup delay

[jarvis24]

That's a beta version. It should (at this date, Dec 2, 2010) read 2010.2.x.x in order to indicate that it's a final "official" release of v2010. I would suggest uninstalling and downloading the current non-beta version from www.empirisoft.com/download.aspx.

[jarvis24]

If you run the "Voice Response" setup utility from the DirectRT v2010's Tools menu--do you see a microphone input listed there? We've discovered on the machines here that if a valid sound input device is not listed then it creates a lengthy delay when DirectRT starts to run an input file. Try to use the utility to see if it can capture your test voice response times. When I selected a valid microphone input and saved the settings, DirectRT started up very quickly once again. Would be curious to know if anyone else finds this as we look for a better solution. This assumes that the delay in DirectRT happens regardless of whether it's run from within MediaLab or on its own.

[Jan]

I also noticed that in DirectRT 2010, there is a varying delay when starting DirectRt from within Medialab (about 1 to 5 seconds, sometimes longer). What has been particularly problematic is that if the participant makes a mouse click within this time frame, the purple medialab window will stay in the foreground and directrt will run invisibly in the background. Even a doubleclick on the continue button in medialab can cause this behavior. Unfortunately, the microphone setting didn't help.
(Win Xp/Windows7, Medialab 2010.2.19 , DirectRT 2010.2.103.1115)

[jarvis24]

In going through the code for the new 2010 DirectRT v2010.2.103.1115, I've noticed a potential cause for a delay *if* IP licensing is being used. It's going to to the internet to compare and validate the IP rather than simply getting the value from Windows. It was a security measure but I expect it could add a variable delay to the startup of a DirectRT session because the IP check is run any time a session is run. Are the delays mentioned in the posts above tending to be happening on machines with IP licenses? If so, why don't we try a manual (i.e., m10... ) license on one of them and see if that resolves it. If so, then we'll fix the IP coding so that it will not slow down the start of any given session.