Version 2008.1.0.11, windows 7
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., fake4! instead of _fake4.mid
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?