Trouble with multiple RTs when using sound files (case 436)

i'm trying to time responses to certain notes in a song.

to make it simple for testing, i took a midi file at exactly 60 bpm (homemade),
and made an experiment that plays the song in the background while
the participant press spacebar every second (onbeat).
after running this a few times, if i add up the times in the 'Time' columns
(the time between every press of the spacebar)
after~40 notes the response time deviates ~500ms.

this makes it very hard for me to automatically determine whether or not
the participant responded quickly enough to a specific note - the participant
has a window of 1000ms to respond, and if the delay around not #40 is 500ms
the participants' window closes to about 500ms.

when i try this expermient out on myself, i may be off a couple of millisecs on each beat, but not half a second...

attached is the midifile, the input trial file and the output log.




is there any way to calculate the response times in such a way that corresponds to the midi file? or any other workaround?




thanks for any help


[I][Note from moderator -- second post begins here][/I]

first of all, this is similar to my previous post,
but with a wav file instead of a midi file (because i thought maybe the non-native media-player needed to play midi files caused bad timing), so sorry for the duplicity..

anyway, i wrote an experiment where the participant listens to a melody and presses space every tie he/she hears a wrong note.
i need to be able to test the response times, to see if the participant responded in under a second, so the timing is critical.

i found out that the closer to the end of the melody i get, directrt 'adds' more milliseconds to my response time - about 1 second every 2 minutes.

(if anyone is skeptic about my conclusions, read the parenthesized paragraphs:



(
after doing some test runs on myself, i found that even though i new exactly when the notes would appear and i reacted in under 0.5secs, if the note was near the end of the melody directRT said it took me over one second to react.

i didn't think it was my fault, so i tried a new test: a created a midi file with a single note every second exactly, converted it to a wav file and ran a test run - i reacted every note.

what i expected to see is a reaction time of (approximately) 1000ms on each stim, and a total of around 60,000 ms by the last stim - that is, if i sum up the response times of every stim (60 notes, around 1000ms response time per note) i should get around 60,000 ms.
but i get around 500ms of deviation - around 65,000 ms.)
)




is this a known issue? is there anything i can do to eliminate the inaccuracy?


attached is the output log, the midi file (not used in the experiment)
and the log_tweaked contains the result of summing up the RTs:
1. column M sums up the RT column (column L)
2. column N sums up all the "Time N" columns (should be more accurate, but still isn't enough)

i couldn't upload the wav file, no trick with zipping it or anything worked... if someone replies asking for it i'll give it another shot.

please help me out, i'm on a deadline... even a simple "yeah, it's a problem and can't be solved, here's why:" would be okay.

a solution would be better, though.


thanks for any time anyone can spare

What version of Directrt (20xx.x.x) are you using, and on what version of Windows?

Version 2008.1.0.11, windows 7

A few thoughts. First--could you create two alternative versions of your .wav version? A 30 second, and a 120 second? Then run the exact same test you described above--i.e., to see if the timing deviation you saw repeats itself in proportion to the length of the clip--or if it gets worse as the clips gets longer? If it's the latter, then it may be a memory leak issue. However, if it's 250ms, 500ms, and 1000ms respectively, then it would seem more likely to be an internal coding issue. In either case, we could also try looking at the 2012 version to see if that resolves it.

PS., not sure why zipping or simply attaching the wav file would work. It may be a file size issue. Not sure, but there may be a 10mb limit on here. You could always email it as an attachment to support @ empirisoft.com. Just make a reference to the URL of this thread.

PPS., you could also try the .wav file version using it as a sound file instead of as a movie file, i.e., [I]fake4![/I] instead of [I]_fake4.mid[/I]

when i used the midi file, i used the _fake4.mid syntax.

the only reason i switched to .wav files is because i thought that the fact that directRT uses a non-native media player to play non-wav files may cause the time deviation,

so i switched to .wav files and used !fake4 syntax.

...and then i posted my second post :)

Could you email me the .wav file? i.e., to support@... Asd well as the "fake" syntax file if it's different from the A1maj.mid_experiment.csv file attached above?