• SONAR
  • MIDI "Jitter" - It Does Exist (p.5)
2007/10/07 16:49:35
dstrenz
Interesting info on the various ppqs used with various sequencers. Now that you mention it, I do recall reading that the Fantom uses 440ppq. It's hard-coded and can't be changed. But I don't really know how much ppq that accounts for the different feel though. The internal Fantom sequencer has the luxury of being able to record while monitoring in real-time, because all of the sounds and effects are built into it too. There is no length of midi cables to worry about, or round trip monitoring, or programs running in the background.. Latency can be calculated and accounted for very precisely since all variables are in the box. I imagine that it uses the old reliable Roland MPU smart mode concept of buffer and timestamp when recording.
2007/10/07 16:55:36
altima_boy_2001
ORIGINAL: dewdman42
Getting a little technical, in Windows there is a timer that has historically been used, called a Multimedia timer. It is supposed to have 1ms accuracy. However, experiments with this timer have shown that it jitters all over the place in real world situations. Some tests even showed it like +-15ms...yikes! That was a few years back though before XP. In addition, if the software using it is not careful, then GUI use and such can make things even worse.

Has anyone done tests to see if increasing Sonar's process priority level affects midi jitter?

Task Manager -> Processes, right-click on Sonar process and increase priority...


If you think timing is being affected by other processes taking up the cpu maybe turning off other programs/services would help alleviate this problem somewhat...
2007/10/07 17:05:38
dstrenz
I actually had the Voyetra mpu clone too. As I recall, it only cost about $300 which was significantly less than Roland's. I too wrote a little 8-track sequencer (using smart mode) in Turbo Pascal, and asm for the interrupt handler. That was convenient because it only handled 8 tracks natively. It worked fine. Then I added some brain-damaged brute-force algorithm in a feeble attempt to generate music. I've got an old recording of it playing through an FB-01 but am too embarassed to post a link. What a terrible waste of time.
2007/10/07 17:08:03
RTGraham

ORIGINAL: dstrenz

I actually had the Voyetra mpu clone too. As I recall, it only cost about $300 which was significantly less than Roland's. I too wrote a little 8-track sequencer (using smart mode) in Turbo Pascal, and asm for the interrupt handler. That was convenient because it only handled 8 tracks natively. It worked fine. Then I added some brain-damaged brute-force algorithm in a feeble attempt to generate music. I've got an old recording of it playing through an FB-01 but am too embarassed to post a link. What a terrible waste of time.


LOL.

Mine attempted to use random variables screened through a probability filter to generate, er, music. Yeah, that's what we would call it...

Only problem was, although it would step through the sequence properly when slowing down the compilation process, it would choke in realtime.
Never figured it out - I'm definitely more of a musician than a programmer.
2007/10/07 17:15:22
dewdman42
The lower PPQ's are more accurate, less jitter, mostly because they are closer to what the operating system can reasonably handle accurately. If you try to go for too much precision, then sometimes the OS will deliver exactly on time and sometimes it will be late, thus jitter. If you use the lower PPQ, then theoretically....the OS is more likely to have time to deliver on schedule. But a lot of that depends on how the software is implemented. But I do know that I read this in a midi C programming book once, that lower PPQ will result in less jitter.

As far as drums and timing accuracy, I hear you. consider this though. 240 PPQ is 480 ticks per second at 120bpm. That is essentially a 2ms level of precision. That is not really a musical form of quantization but its also barely audible by only a few golden eared people. 480 will give you 1ms if you want. If you can live with the random jitter. RTGraham says he didn't notice much difference going to lower PPQ, but that he always had 1-2ms of jitter anyway. (shrug).

The hardware pieces undoubtedly have much less jitter, but if they are set to 200PPQ internally, then in a sense, they are introducing the same low precision that 2ms of jitter will give you.

Regarding hardware timestamps...to my knowledge the only midi interfaces that ever did this are the MOTU's (possibly not even all of them), the one from Emagic and Steinberg made one also. At the time I remember hearing that you had to use the MOTU one with Digital Performer and the Emagic one with logic and the steinberg one with Cubase, in order to take advantage of the hardware timestamping. However I had some email exchanges with MOTU a while back when I was thinking of using my MOTU midi interface with Logic on the mac and I was told by him that the timestamping should work with Logic too. I will try to dig up the email if people are interested.

This was done at a time when all of the sequencers were suffering badly from Win2k-itis. Since then the XP midi handling has been improved sufficiently enough that they no longer need to market such things. I'm not sure if the Emagic or steinberg interfaces are made anymore, but the MOTU's still are.

Regarding the older MPU-401. My understanding is that it did not actually timestamp midi events in the hardware. The timestamping of midi events happened in the card's driver software. However, those older midi cards were interrupt driven. So when a midi event came in, the driver would usually trump anything else that was running on the cpu to immediately timestamp the event in the driver. Personally I had terrible midi performance with an MPU-401 and early versions of cubase, so I can't say it was any better, but I know the driver is where most midi interfaces timestamp the events.

The difference with the MOTU interfaces is that they timestamp the midi event in hardware the instant it is received on the midi port, then the driver will eventually kick in and use the timestamp that was already created by the hardware. You still want the driver to react as quickly as possible because if you are playing a VSTi or something in realtime, you want low-latency. But the accuracy of the timestamp in that situation is based on an earlier timestamp that did not have to wait for the OS to give the driver time to do it. The only dependency is whether the MOTU driver passes the hardware timestamp along to the host DAW, which MOTU told me once that it does. So as long as the host software is using the timestamp created or recognized by the MOTU driver...then it should be the hardware one. If Sonar makes its own timestamp(which would be dumb), then jitter times would be much much worse and hardware timestaming would be moot.

Playback, however is another story.



2007/10/07 17:41:24
evzevz
Wow this thread came along at the right time for me (pardon the pun)... I've been having some horrible playback on midi stuff lately - the only thing that seems solid is my ez drummer stuff... But everything else has been more off than Steve Martin in the Jerk... turns out my latency setting had been pushed way up beyond where it needed to be (at 137.7 or so), and this was creating the problems... I brought it back down to 26.6 and now all is solid again... Very odd, but thanks to ModBod for the tip...
2007/10/07 17:46:06
dewdman42
when you say off? what does that mean? Constantly early/late, or jittery?

I'm surprised to hear that a large audio buffer setting would cause the midi timing to be off. If that is the case, then THAT is definitely a bug in Sonar! Unless you are referring to the fact that with a large buffer setting you hit a key on your keyboard and hear it much later... that has nothing to do with our current discussion if so.


2007/10/07 17:51:10
evzevz
Dewdman - I don't mean latency, I mean playing back midi parts with correct feel and timing - really choppy and inconsistant timing... almost a stuttering, but always varied somewhat - in other words, loop over the same measure and it messes up differently every time thru.
2007/10/07 17:53:00
dewdman42
Ya, that is jitter alright....and that sounds like a bug to me. A larger audio buffer in theory should give Sonar MORE time to do everything it needs to do, including deliver midi events on schedule.

Well now I want to do some experiments myself... (sigh). I sure hope cakewalk is not losing midi tightness in exchange for all the features they've been adding.
2007/10/07 17:53:38
dstrenz
ORIGINAL: dewdman42
Regarding the older MPU-401. My understanding is that it did not actually timestamp midi events in the hardware. The timestamping of midi events happened in the card's driver software. However, those older midi cards were interrupt driven. So when a midi event came in, the driver would usually trump anything else that was running on the cpu to immediately timestamp the event in the driver. Personally I had terrible midi performance with an MPU-401 and early versions of cubase, so I can't say it was any better, but I know the driver is where most midi interfaces timestamp the events.

The difference with the MOTU interfaces is that they timestamp the midi event in hardware the instant it is received on the midi port, then the driver will eventually kick in and use the timestamp that was already created by the hardware. You still want the driver to react as quickly as possible because if you are playing a VSTi or something in realtime, you want low-latency. But the accuracy of the timestamp in that situation is based on an earlier timestamp that did not have to wait for the OS to give the driver time to do it. The only dependency is whether the MOTU driver passes the hardware timestamp along to the host DAW, which MOTU told me once that it does. So as long as the host software is using the timestamp created or recognized by the MOTU driver...then it should be the hardware one. If Sonar makes its own timestamp(which would be dumb), then jitter times would be much much worse and hardware timestaming would be moot.

Playback, however is another story.



The mpu definitely did timestamp the events in hardware in Smart mode. In the other mode, UART mode, it merely passed the midi events through, acting like a simple serial port. I had the Voyetra sequencer and an early version of Cakewalk then and one of them, (I ?think? it was Cakewalk), let you choose the mode. As computers got faster, smart mode went away completely.

For playback, smart mode would not work at all today because there would be no way to synchronize it with audio. You'd send a 'start play' message to the mpu. The mpu then began requesting timestamped midi data (again through interrupts), buffering it, and pumping it to the midi out port, taking care of all the timing for you. That was handy but you'd have no way to determine how to sync up audio because the timing was handled in the hardware.
© 2026 APG vNext Commercial Version 5.1

Use My Existing Forum Account

Use My Social Media Account