Reason / DP / OMS Test Results Within...
The following is a post by "Big Daddy" copied from the Unicornation board... I though it might be of interest here:
Okay, here are the results of the BDRTT - A.K.A. the Big Daddy Reason Timing Test (insert trumpets here). Sorry about the long-winded nature of this reply, but I think that the DP/Reason users here will find this info very helpful. I apologize to Meltdown as well - This should have been a quick and dirty test, but I never, ever... ever do things quick and dirty
To start with, I used DP 3.11, buffers set to Disk Read/Write size 200 and Buffer per voice 400. Pre-fill is off. Custom studio size of 16 mono and 32 stereo tracks, with 16 Stereo buses (yes, I have lots of ram). Sound card is an Audiophile 2496. Fine tune audio I/O timing is set to 0 playback and 0 record (no tweaking in other words).
The project was set to 16bit 44.1 khz for this test. Using Reason 2.01 and OMS Emu to communicate with DP. Interface is a USB Fastlane for incoming midi (from my controller) and a MOTU MTP (the original) connected to an external midi module (Kawai XD-5 Drum module). The MTP is connected via serial cable to a Griffin g4Port serial adaptor. Reputed to have excellent midi timing.
First thing I did was to record a midi click track routed to my external midi module. I actually use it as my metronome for DP. Quantized at 100%, I then copied the midi track to another midi track and routed it to a ReDrum module in Reason. I wanted an audio reference as well so I recorded about 20 bars of the ext. module to an audio track in DP so I could later compare the timing differences between Reason in real time and a recorded audio track, as well as comparing it to the ext. module in real-time.
With the cards buffer at 256 samples, comparing Reason to the ext. module in real time showed a very (and I mean very) slight difference in the timing. Not enough to even worry about. Comparing Reason in real-time to the audio click track revealed the same findings.
Next, I bumped my sound cards buffer to 512 samples and compared the two again (real-time). This time, I could hear an actual flam between the two notes (for non drummers, a flam is two very closely placed beats, which are not meant to sound like two distinct beats. 2 beats = boom boom whereas a flam = boboom). The amount of the flam was minimal, but it was there. In order to line up the timing of the tracks again, I had to shift the Reason track ahead by 8 ticks. I also noticed another thing. The timing would fluctuate here an there. I can't say if it was Reason or my ext. module, but there was a sort of lag and catch up thing going on. We're not talking enough to make the two beats sound like an echo or anything, but something was not 100% on the mark.
Now, I upped the card to 1k samples. The flam became more obvious and this time, I had to shift the Reason track ahead by 21 ticks to line them up again. Also, the fluctuation seemed to be getting worse.
Comparing Reason to the audio click track I recorded from the ext. module (i.e. Reason via OMS Emu in realtime vs. audio click track from ext. midi module) revealed that Reason's timing was slipping more an more as the buffer went up.
As I went along, I recorded the audio from the ReDrum into a DP mono track as well. Oddly enough, when I compared a real-time ReDrum track to an audio ReDrum track (buffer settings being equal) the tracks were not perfectly on either. In fact, they seemed to fluctuate between nearly dead on for 1 bar and then slightly off for 1 bar. In a perfectly repeating pattern to boot. 4 beats on, 4 beats off.
As a last experiment, I decided to record a midi click track in Reason's sequencer and compare that to the ext. module (being driven by DP) and also the Reason midi track in DP, routed via OMS Emu. at the various sound card settings.
With a card setting of 256 samples, the Reason sequencer track was slightly ahead of the midi module. Imagine that... I had to shift the module ahead in time 9 ticks to line them up. And when they did line up, something became very clear. The fluctuation I mentioned earlier was now gone. The two tracks played back on time and stayed on time for the 20 or so bars. When comparing Reason to itself (one midi track in Reasons sequencer and the other in DP) the timing was just slightly off and it fluctuated (got worse as the buffer went up).
Bumping the card up to 512 samples, I figured that Reason would now be right in time or slightly behind DP and the ext. module. To my suprise (maybe horror) the ext. module was still lagging by 9 ticks. How could this be???
Okay I said, up to 1k samples and we'll kick some Reason butt now. Er... maybe not. The ext. modules track had to be shifted ahead 10 ticks this time. How can Reason be getting better as I raised the buffer setting on my soundcard? How could an external midi module be slower than software?
Finally, I tried a 2k buffer setting on the card. Same result. The midi module was now behind by 10 ticks. Um... huh??? Comparing Reason to itself again (as above) the timing was off quite a bit and the fluctuations were horribly noticable.
These are some of the conclusions I came to after running these tests. Feel free to comment and point out any possible flaws in my logic, seriously!
(1) OMS Emu is crap, timing wise anyhow. I love that it's stable and I rarely need 100% accurate timing for what I do, but come on now. I can deal with latency, but the fluctuating back and forth was crazy. Maybe OMS Emu has a built-in Humanize feature that I'm not aware of
(2) DP's midi timing is crap. No way. Once I took OMS Emu out of the picture (by using Reason's sequencer) the fluctuations went away and the ext. modules track was solid, if somewhat behind Reason.
(3) I attribute the fact that Reason, when using it's own sequencer, never lagged behind DP to the Prop's designing one heck of a nice audio latency compensation algorythym in ReWire. By this I mean that, while the sound cards buffer was set higher and higher, Reason adjusted it's midi to audio timing in such a way that it never fell behind. Not too shabby. Obviously, when trying to record a midi track into Reason (or DP) with a buffer setting above 256 samples, the latency of the sound card rears it's ugly head. So be it. My mac is fast enough to deal with a buffer setting of 256 samples for 99% of the work I do.
(4) From here on in, I think I'll record and edit all my midi tracks in DP and drive Reason via OMS Emu as usual. However, when it comes time to lay down Reason tracks as audio, I'll export the DP midi tracks as a standard midi file and then import it into Reason. Why not go with the best timing possible right?
(5) DP 3.11/MAS 2.4 and Reason 2.01 are pretty damn stable. Throughout this test, spanning maybe 3 - 4 hours time, I must have switched DP's audio system between MAS and Midi only (so I could adjust the sound cards buffer) at least 100 times. With Reason running in the background and my switching back and forth between the two apps constantly... DP never even flinched.
If you want to drive Reasons modules from DP using OMS Emu, then you'll have to keep the buffer settings low (128 - 256). Your timing will be tighter, but there will still be that timing fluctuation introduced by OMS Emu. At 128 samples, it's probably so minimal that most wouldn't notice.
(copied by Drew)
Catch 22 - featured at ElectronicScene.com
Well i will be damned
Concur with everything that was said. I always wondered why it would sound solid when I was driving reason but then loose when I dumped the audio into dp.
Thanks for reposting that drew.
Re: Reason / DP / OMS Test Results Within...
I also have percieved this timing sloppiness. I'm using the same setup but with OMS IAC bussing rather than Emu. Is there a difference?
- Ken French
|All times are GMT +2. The time now is 23:13.|