|
code
newsgroups
|
|||||||||||||||||||||||
|
|||||||||||||||||||||||
MMTimer, DirectSound, and For..Nextto play the Wav files, and I use the TimeSetEvent function in winmm.dll for my timer routine. I am having a couple off issues that need to be ironed out and I am at a loss. Here is the deal... The timer works perfectly. I tested it by creating a label, storing the time that I start playback, storing the time that I stop playback, and subtracting the number of milliseconds that the timer should have fired in this timeframe. The result is written to the label... No matter how long I run the timer, it was only off by 1 or 2 milliseconds over the life of the timer, which could simply be due to how long the code takes to intitialize the timer the first time. No problem there. Issue number 1... I record my song (90 BPM) in realtime into another (professional) application (sonar) at 90 BPM and my program drifts over time. Other pro applications sync perfectly using the same procedure. I KNOW for a fact that my BPM calculation is correct... So, ??? Issue number 2... (They are probably related) The user can program up to 24 drums to fire simultaneously. In testing, when I do this, you can hear that the drums are not firing at exactly the same time. This is probably due to the fact that I am using a For Next loop in my procedure. It literally goes through all 24 "drums" to see if each one is "on" and calls another proceedure that loads then plays the wav file if necessary. Is it possible that the For/Next is taking too long to excecute and is somehow affecting my timer? Is there any way to NOT have to load the wav into the DSbuffer before playing it, perhaps this is where the delay is? Does it make sence to have 24 DSbuffers instead of one? Is there another way to test this to find out where the delay is coming from? Any ideas will be greatly appreciated. Frank FrankAm wrote:
> I record my song (90 BPM) in realtime into another (professional) Problem found, you are expecting a drummer to keep in time :-)> application (sonar) at 90 BPM and my program drifts over time. Other > pro applications sync perfectly using the same procedure. I KNOW for a > fact that my BPM calculation is correct... So, ??? > Q. How do you know there is a drummer at the door? A. The knocking speeds up. -- Robin. "He who treats the database as a flat-file repository of data is doomed to burn in Hell. It's true, I asked." - Dratz I know I cannot keep perfect time, this is why I need a drum machine
program, I thought computers were supposed to be perfect? ;-) Actually, my program sounds great being a little "off", very human. But this is no good when the beats need to be shared with other programs. FrankAm wrote:
> I know I cannot keep perfect time, this is why I need a drum machine I am afraid my wise crack might be the most useful thing I post on this > program, I thought computers were supposed to be perfect? ;-) > > Actually, my program sounds great being a little "off", very human. But > this is no good when the beats need to be shared with other programs. thread, but I will give it a go (FTR, I'm a Bass player.) Timers in windows are not spot on, they are 'round about'. The problem with using this for sound is that the ear, unlike the eye, is very precise and picks up on irregularities in an unforgiving manor. Where the eye will 'trick' you and adjust to things, the ear will make a slight problem stand out like dogs teeth. (as you would well know). Timers are effected by cpu usage etc. I guess one sound is taking up cycles slowing down the start of the next one. I guess you might be able to get this really close, but AFAIK using timers you will forever be at the mercy of this. -- Robin. "He who treats the database as a flat-file repository of data is doomed to burn in Hell. It's true, I asked." - Dratz I agree, but...
How is it that Sonar, or a host of other pro applications can deliver PERFECT time running under windows? Also, in testing my timer IS indeed accurate, the problem must be something I am doing in my routine. This is why I posed the question, does the loading of the wav into the buffer (24 times in a loop) and subsequent playing of the file slow the timer down, and my test is not catching this fact? On 21 Mar 2006 11:57:40 -0800, "FrankAm" <frankamend***@sbcglobal.net> <quote>wrote: >I agree, but... > >How is it that Sonar, or a host of other pro applications can deliver >PERFECT time running under windows? > >Also, in testing my timer IS indeed accurate, the problem must be >something I am doing in my routine. This is why I posed the question, >does the loading of the wav into the buffer (24 times in a loop) and >subsequent playing of the file slow the timer down, and my test is not >catching this fact? The timeSetEvent function starts a specified timer event. The multimedia timer runs in its own thread. After the event is activated, it calls the specified callback function or sets or pulses the specified event object. </quote> In other words the CallBack is coming from another Thread, and VB6 does not support multiple threads (normally) at all safely. Other languages support multiple threads and those Applications probably use SetThreadPriority. "FrankAm" <frankamend***@sbcglobal.net> schrieb im Newsbeitrag Definitely yes (as long as your Ram is large enough).news:1142919038.804347.279120@j33g2000cwa.googlegroups.com... > Does it make sence to have 24 DSbuffers instead of one? You should also try to work on an absolute time-base. Get your StartTime - then enter the Loop and set your MMTimer-Interval to 5msec or below. Look inside each Timer-Event for the actual Time-Delta ((CurTime-StartTime) Mod YourRealInterval) and decide from this values, when to play your SoundBuffers. Olaf |
|||||||||||||||||||||||