ORIGINAL: pianodano

In the instance quoted I am referring to a tweaked (perfectly satisfactory) midi track which is driving the softsynth and what then happens to the audio after said audio is frozen. Realguitar is a perfect source to test this because every note has a strong attack. It may play along perfectly for a while and then suddenly 2 or 3 notes get screwed up. Somehow during the freeze process the audio becomes slightly mis timed and it usually continues to get worse. YMMV. It is a part of the frozen track and will always be and start in the same place - Not randon.

Yea man, I hear ya. I'm trying to identify whether the problem is that the freezing process is messing it up, as you believe, or if rather, the whole time you are tweaking it in the PRV...what you are hearing is not correct...you tweak it and make it "sound" correct..but then the freezing process makes it sound wrong again...perhaps the frozen version is actually exactly what is shown in the PRV, but what you tweaked in the PRV was made wrong because you weren't hearing it right while you were tweaking it...see what I mean? I'm much more suspicious that the midi track plackback unfrozen would be incorrect than that track freezing would be wrong...but then again..who knows.... Sounds like something is not right somewhere in there though...

ORIGINAL: dewdman42

The problems that I keep hearing people talk about on here I think are mostly much greater than 1-2ms of discrepency. That implies to me they are having DRASTIC midi timing problems under certain circumstances and those are the situations we need to identify and try to get Cakewalk to fix. I've heard a scattering of stories here, but one common theme seems to be related to audio buffer sizes and I'm wondering if delay compensation is a culprit here.

That sounds right to me. When I was a MIDI test-aholic (around 2000) - I found some truly 'pathological' situations where audio and MIDI drivers clashed. MIDI jitter of 80 to 400 milliseconds (yes, up to four hundred) could easily result.

1st-generation USB MIDI interfaces tested out at 7+ milliseconds of jitter, btw. Newer ones have been measured (by Martin Walker) with jitter levels around 1-2 milliseconds.

What we need -- is a fairly simple way for Sonar users to test their set up, and see if it's gone really wonky.

Ok, I just Googled. The easiest way to test MIDI latency, today, is probably with the Miditest utility written by Evert van der Poll. See http://www.soundonsound.com/sos/apr04/articles/pcnotes.htm for a writeup. See http://earthvegaconnection.com/evc/products/miditest/index.html for the actualy utility (freeware). Caveat: I haven't tried it myself, and can't vouch for it. If you try it - let us all know how it works for you!

- Jim

ORIGINAL: Jim Wright

Agreed: that's not the answer. What's needed is a) MIDI interfaces that really timestamp; b) MIDI drivers that respect timestamps; c) MIDI sequencers that use timestamps, every step of the way.

Yep. Seems like everyone gave up on that when most consumers decided that 1-2ms of jitter was acceptable. (shrug). hardware timestamping during record is the only way around XP and OSX limitations IMHO. Playback is another story, pretty difficult for external midi, but Sonar should absolutely be able to make sure that playback to softsynths during mixdown and freezing is 100% jitter free. Even playing back a project through softsynths should be jitter free as far as I'm concerned...if there are problems...then it must be related to various buffers and programming in Sonar that needs to be improved.

Since the standard Windows 'MM' MIDI driver stack doesn't use timestamps - look for MIDI interfaces that support the DirectMusic Core API (which does). Since stock USB MIDI doesn't use timestamps (and has inherent jitter of 1-2 msec in every USB interface I've seen) -- look for alternatives if you want lower jitter than that. What alternatives? PCI-based interfaces (EMU still makes them, cunningly disguised as an EMU 1616M and the like). Non-stock USB interfaces (i.e. the MOTU interfaces that use their own proprietary MIDI timestamping protocol). Firewire interfaces (The Firewire MIDI spec doesn't timestamp, but does support accuracy down to 1/3 millisecond).

Yea. I have to say though, I have MOTU traveler and the midi is VERY latent compared to my MOTU parallel port interface. Probably not the fault of firewire, it probably has timestamping though.

It would be a big help if Cakewalk would test Sonar's MIDI timing performance with different MIDI interfaces, and post the results. Now, that might tick off some of the MIDI interface vendors - but it would certainly be a service to Sonar users.

Yea, that would be nice.

ORIGINAL: dewdman42

The problems that I keep hearing people talk about on here I think are mostly much greater than 1-2ms of discrepancy. They are blatantly bad midi timing glitches. That implies to me they are having DRASTIC midi timing problems under certain circumstances and those are the situations we need to identify and try to get Cakewalk to fix. I do not think Cakewalk can do anything about the 1-5ms range of jitter due to limitations of the operating system.

I've heard a scattering of stories here, but one common theme seems to be related to audio buffer sizes and I'm wondering if delay compensation is a bigger culprit here with some of these stories about seemingly drastic midi timing problems.

You're on to it now. Look in my case, I'm getting older now so I really don't expect my timing to be as precise as it was in the 70's and 80's. But dag nab it, I had tempos drilled in my head so many years, I felt like an atomic clock. I can nail it on tape OR if I startup the old MC500 I can still hit pretty darn close to a consistent 5 to 10 ticks late (its 480 or 96tpqn) if I feel the part should be laid back that way. But I cannot reliably put it in the pocket with my current DAW setup.. I really wish I knew why.

ORIGINAL: dewdman42

ORIGINAL: pianodano

In the instance quoted I am referring to a tweaked (perfectly satisfactory) midi track which is driving the softsynth and what then happens to the audio after said audio is frozen. Realguitar is a perfect source to test this because every note has a strong attack. It may play along perfectly for a while and then suddenly 2 or 3 notes get screwed up. Somehow during the freeze process the audio becomes slightly mis timed and it usually continues to get worse. YMMV. It is a part of the frozen track and will always be and start in the same place - Not randon.

Yea man, I hear ya. I'm trying to identify whether the problem is that the freezing process is messing it up, as you believe, or if rather, the whole time you are tweaking it in the PRV...what you are hearing is not correct...you tweak it and make it "sound" correct..but then the freezing process makes it sound wrong again...perhaps the frozen version is actually exactly what is shown in the PRV, but what you tweaked in the PRV was made wrong because you weren't hearing it right while you were tweaking it...see what I mean? I'm much more suspicious that the midi track plackback unfrozen would be incorrect than that track freezing would be wrong...but then again..who knows.... Sounds like something is not right somewhere in there though...

Man you have good insight on the issue. Interesting hypothesis.

Thanks

ORIGINAL: pianodano
You're on to it now. Look in my case, I'm getting older now so I really don't expect my timing to be as precise as it was in the 70's and 80's. But dag nab it, I had tempos drilled in my head so many years, I felt like an atomic clock. I can nail it on tape OR if I startup the old MC500 I can still hit pretty darn close to a consistent 5 to 10 ticks late (its 480 or 96tpqn) if I feel the part should be laid back that way. But I cannot reliably put it in the pocket with my current DAW setup.. I really wish I knew why.

ah ha. MC500 was 96ppq. Well playing into a pocket is not needing necessarily more than 96ppq. You are still essentially getting it to land your notes evenly on a tick. So in fact, the 96ppq was actually giving you an automatic form of input quantize, which made your parts sound tighter..because even if you were actually playing a little looser than you might think...the 96ppq was input quantizing you, mostly to the correct tick for each note. See what I mean? And then when you played it back, it sounded even tighter than when you played it....but 96ppq is precise enough to not sound "quantized". The main advantage at that point is the zero jitter that the MC500 was giving you, making your grooved performance sound absolutely tight according to a 96ppq grid.

In case you're wondering, 96ppq = 1/128th triplets.

I don't think you can ever get this from Sonar except with a midi interface that does hardware timestamping. If you get an interface like that, then set the resolution to 96ppq and try it out. The sonic latency will be off though...which might screw you up, but timing wise that should be as close as you're going to get to it. Otherwise, use the MC500 or get a Mc-50mkII and transfer the tracks to Sonar after laying them down. The OS limitations will not solve that problem.

However, the track freezing issue is something else entirely I think.

By the way, one review I read about one of the MPC's said; that the argument from Akai about why 96ppq is enough? They said that their feeling is that if you need more than 96ppq precision then you should just record directly to tape without any quantization at all.

Of course, that assumes you are a pro with the skills to play every note accurately to tape, and also that you have no desire to alter the sound source after the fact or editing the notes creatively. Kind of a weak excuse if you ask me. But undoubtedly there are constraints and we don't really know for sure that the expensive 480ppq MPC is jitter free. Perhaps the older boxes are jitter free only because they use a low resolution of 96ppq which give them 5ms between every tick to do what they need to do.

Myself, I prefer to record without quantize and then I go fix the few odd notes that I was too loosy goosy on. The rest are unquantized. But now you have me thinking that I would probably be best off most of the time using something like 64-128ppq to basically be a form of input quantize.....most of the time. Occasionally I would need to lay down something with more precision. But if the jitter is off by 1-2ms anyway...a lot of this is kind of a moot point anyway. However, it does show a nice advantage to using a hardware sequencer for laying down grooves..and that is probably not likely to change for quite a while.

PianoDano, one suggestion I would have for you is to try recording with input quantize set to 1/128th notes or 1/128th triplets. The jitter will still be there...but perhaps the input quantize will mostly correct the notes to where they need to be. it will mostly fall into that tight performance you used to get with the MC500.

However, playback jitter, and the freezing problem..that may still be a problem I guess....

Thank for the details, Jim (and pianodano)! It's getting late so I'll test tomorrow evening and post the results.

Greetings amigos!

You may be interested in the article, Inside Windows NT High Resolution Timers available at http://www.microsoft.com/technet/sysinternals/information/highresolutiontimers.mspx

"High resolution timers are desirable in a wide variety of different applications. For example, the most common use of such timers in Windows is by multimedia applications that are producing sound or audio that require precise control. MIDI is a perfect example because MIDI sequencers must maintain the pace of MIDI events with 1 millisecond accuracy. This article describes how high resolution timers are implemented in NT and documents NtSetTimerResolution and NtQueryTimerResolution, the NT kernel functions that manipulate and return information about the system clock."

There's also a tool at http://www.microsoft.com/technet/sysinternals/SystemInformation/ClockRes.mspx to tell your your Clock Resolution

I get 15.6 ms on my system.

Note that this tool is only supposed to operate correctly on NT4 or Win2k. Its not designed for XP.

Nonetheless, many tests have been done by people showing that 1ms is almost never obtained in reality.