On Mon, 31 Dec 2001, Chris Kennedy wrote: > >I've posted a win32 binary up to date with current CVS @ > >http://www.clock.org/~matt/freesci/freesci-win32.zip . > > I picked up the latest CVS, but used your binary and SDL.dll to eliminate > extra variables. > > >Please test and let me know if you run into any problems. > > Alrighty:
Thanks for testing! I knew you would run into some problems, but just wanted to make sure they were consistent. Using my binary and SDL.DLL weren't necessary, but I appreciated the diligence. Here's what I've figured out so far. 1) MIDI problems under win32 have known workarounds: http://msdn.microsoft.com/archive/default.asp?url=/archive/en-us/dnargame/html/msdn_mlatency.asp This is why the use of timeSetEvent in the SCI Windows Interpreter works and ours doesn't (not as well, anyways). Their CALLBACK is in a 16-bit DLL (their whole program is 16-bit). 2) You aren't supposed to do what we're doing inside a CALLBACK function. They really only want you to use PostMessage, timeGetSystemTime, timeGetTime, timeSetEvent, timeKillEvent, midiOutShortMsg, midiOutLongMsg, and OutputDebugString. This turns out to be alright, actually. timeGetSystemTime can be set to return the time in ticks from a MIDI stream. We can poll this, which should be less expensive than using QueryPerformanceCounter. I'm going to try this possible solution today.
