BTW if you still don't believe us and want to verify this further :-) you can download the source code to TWONAR from our DXi2 SDK to see exactly what its doing.
Ron Kuper wrote that plugin so its not supported anymore - his home phone number is encrypted in the code though :-)

We use the standard Windows midiXXX API's to talk to MIDI drivers. User mode applications do not do any kernel mode processing.

That's what I more or less have been assuming. So 1ms is the actual resolution of Sonar's midi, not 960ppqn, though it may be recorded in numbers on that timebase.

Yes?

The MIDI API sends the timestamp at a 1ms resolution via the midiIn device callback.
During MIDI recording incoming data is queued up at millisecond resolution and then converted to the 960 tick resolution for storage in tracks.

ORIGINAL: Noel Borthwick [Cakewalk]

The MIDI API sends the timestamp at a 1ms resolution via the midiIn device callback.
During MIDI recording incoming data is queued up at millisecond resolution and then converted to the 960 tick resolution for storage in tracks.

Thanks, Noel. That seems pretty definitive to me!

- Jim

Thanks Noel for the clarifiations!

Ok, given that Sonar is hardwired to record midi events at a timer resolution of 1ms, stored with values at a 960 timebase, I think Steve's operating method does make absolute sense to get closest to what is actually happening in the hardware, given that we have no control over the actual timer resolution used.

The reason is because the 1ms intervals do not necessarily land evenly on 960PPQN tick intervals. In fact it completely depends on the tempo. This does not mean that anyone is getting sub-millisecond timing. Nobody is. The best you can expect is 1ms. But, because of the MM timer and the midi clock timer not necessarily being synchronized, errors can result there too which might cause a little jitter right around 1ms.

For example:

At 120BPM, 1ms = 1.92 ticks

When the MM timer goes to get whatever is in the midi buffer, all the midi events that have been received within the past ms are given a timestamp to the same tick. They are going to be rounded off to the nearest tick.

at 180BPM, 1ms = 2.88 ticks. You see the advantage? When rounding off to the nearest tick, there are more ticks to choose from for the rounding. A higher tempo gives you better rounding to the nearest tick essentially.

I suppose if you wanted, you could figure out which Tempos would theoretically provide no rounding errors at all, but its a bit moot since the MM timer is not guaranteed to be in sync with the midi clock ticks, nor is the MM timer that accurate, so eliminating as much as possible the rounding errors seems to be the best bet here, combined with using the best midi interface you can find, preferably not USB.

Noel, As I sit here thinking about it... I think it makes no sense for Sonar to timestamp to 960PPQN. If that is a hardwired resolution or rather should I say, if sonar is going to be hardwired internally to record and play back events at some resolution, doesn't it make more sense to use a larger timebase to get less rounding errors? Then Steve doesn't have to use insanely huge tempos to accomplish the same thing.

Ehhh........., never mind. I find the current resolution just fine. I don't really want to look at 4 digits of resolution in all my various midi edit widgets just to avoid some small amount of rounding jitter +/- around 1ms. At some point we're splitting hairs.

I just switched my USB controller off and am using the midi-out into my parallel-port MOTU interface and can feel a noticeable difference while playing piano. I really think avoiding USB midi is key for discerning people. Given that Sonar always uses the 1ms timer, I see zero advantage to using lower PPQN than 960.

I just ran through your test, and it definitely looks like what you're seeing is introduced by TTS-1. I was able to reproduce your results, although the variations in the spacing of the hits were extremely regular in my test.

Thanks for looking into this, Dave. My test also found the pattern you're seeing, mentioned in an earlier post. Namely groups of three or four intervals that were a little too long, followed by a very short one that would put the net timing close to being back on track.

Testing of the TruePianos VSTi seemed to confirm that any timing issues were a product of the synth itself, and not Sonar, as TruePianos was very consistent and accurate in it's reproduction of event timing.

If the TTS-1 could be improved, that would be great, but it's certainly quite usable as it is. I undertook this investigation more out of curiosity than concern about timing accuracy.

ORIGINAL: Dave Malaguti [Cakewalk]

I just ran through your test, and it definitely looks like what you're seeing is introduced by TTS-1. I was able to reproduce your results, although the variations in the spacing of the hits were extremely regular in my test. (Emphasis added - RTG)

Interesting. TTS-1 still contains Roland technology, yes? I'm really curious to go dig up my old timing test results from the TR-505 drum machine, and see if there's any correlation between TTS-1's timing anomalies and the TR-505's deliberately skewed sixteenth note quantization. My work schedule is extremely intense, and that info was on an old machine, but if I can find it I'll post it.

ORIGINAL: dewdman42

Ideally, Microsoft would mimic Apple and license MOTU's MTS. That way, all the MOTU hardware would instantly become useable under Windows sequencers that use the new model.

Actually, I'm thinking even more broadly. Microsoft should build an API that incorporates a similar feature, and then that should become a standard for all MIDI interface manufacturers to use. I don't want to be limited to just MOTU products - their Windows support is still sub-par, in my experience. In theory, there may be manufacturers whose interfaces already have the internal capability to support hardware timestamping, and those interfaces would be "upgradable" to the new standard through a driver update.