ORIGINAL: Steve_Karl

http://www.sightsea.com/music/singles/safety's_beginning.mp3

Steve, nice music.

ORIGINAL: RTGraham
but it probably also means that the "slop," which is millisecond-timer-related (as opposed to MIDI sequencer clock related), spans twice the number of clicks when it does rear its head.

exactly

It's discussed here a couple of mouse wheels down.

ORIGINAL: RTGraham

Right... however, I can see how doubling the tempo might still be useful to Steve... if he happens to be using an extremely stable MIDI interface, where he's already minimizing his jitter, then he'll be capturing the subtleties of his performance with finer resolution overall, jitter notwithstanding. Wonder what interface he's using.

Originally I had a Voyetra V24 ( I believe it was called ) on the first machine I used CWPA9 on.
It was very good.

Now I have 2 TASCAM pci-822 cards ( pci slot ... in 2 different machines )
No complaints at all.

ORIGINAL: Steve_Karl
Now I have 2 TASCAM pci-822 cards ( pci slot ... in 2 different machines )
No complaints at all.

That is one of the few PCI based midi interfaces out there and I would be very interested to hear the results if you were to run this interface through some of the tests that others on this thread have done. PCI based midi does have the potential to be lower latency and less jitter than USB in general, though you're still dealing with the MM timer which is 1ms on a good day, but can sometimes be sloppy too. But still I would expect that you might very well be getting pretty close to 1ms timing with that interface, just on a hunch..(which is the same as 480PPQN by the way)...not including the other midi slop you get from the midi cable and midi ports on your keyboard.

You might be right, but I feel that is a bug in sonar if true. One thing we do not really know for sure, is whether Sonar is making more trips, more often, to the midi input buffer.

He already said he's using that Tascam one, which is a PCI based interface, which is why I'm curious about what kind of performance he is getting from that interface, it might be quite good.

ORIGINAL: brundlefly

If you're just trying to play to tempo, using a lower PPQN is more likely to get the note where you wanted it and will impose less system resources to do so.

Okay. I'm officially taking a stance: This is NOT true.

I set up a new Sonar project at 48PPQ, saved it as a template, closed Sonar, restarted, opened the template, and recorded some randomly played notes from my keyboard. In the event view, the first four events were at ticks 37, 3, 19 and 10. This would correspond to 740, 60, 380 and 200 at 960PPQ. But when I changed the project to 960PPQ, the displayed tick values were 742, 73, 392 and 201.

Based on this, I feel it is safe to say that Sonar always uses a resolution of at least 960PPQ internally, so there is no value in running at a lower PPQ setting, except possibly if you like the tick values to have a smaller range when you are looking at things in the event view.

I agree totally.
Even if one is using a poorly designed midi interface that reaks with jitter, choosing a lower PPQ is still going to impose limitations that aren't needed.

You guys are both still missing the point that the MM timer is only 1ms and its sometimes not even that. That is the frequency with which Sonar goes to look at what the midi interface has collected. Regardless of what you have set your PPQN to, You're never ever going to get better than that..which means 1ms quantization effectively. That results in a kind of jitter. And that very action of going to look at the midi buffer is EXPENSIVE. The main reason for suggesting to use a lower PPQN is to reduce the overhead. If Sonar is not going to look at the midi buffer less often, then there is no point in lowering it. However, if lowering it does have some impact, then there may be a case for it.

Bottom line, however, is that nothing you think you are doing with your setups is giving you true 960PPQN midi recording from your midi input port. At best its maybe half that. And its probably not that good either. 960PPQN on windows is mostly marketing.

Anyway, I'm unsubscribing from this thread because I feel like I'm beating my head against a wall. The only final comment I can make is to use your ears, do what works for you and have fun. I hope cakewalk will investigate the fact that the PRV is not representing what is actually playing back, that is a bug IMHO.

ORIGINAL: brundlefly

One thing we do not really know for sure, is whether Sonar is making more trips, more often, to the midi input buffer.

Based on the results of the MIDI round-trip test I did at "48PPQ" (wink, wink, nod, nod), I think we do know that it is checking more often.

Also, hearing the difference ( consistently over years ) between 480 and 960 is good enough for me without any numerical tests.

As Yoda said "There is another...." way to improve MIDI timing accuracy on a Windows machine. At least in theory...

Bear with me while I set the stage.
There are (at least) three major sources of MIDI jitter on a Windows DAW.

1) is any jitter that's contributed by the underlying transport (USB, Firewire, PCI). USB contributes at least 2 milliseconds of jitter, for reasons discussed above. Firewire contributes about 0.3 milliseconds of jitter. PCI - contributes very little jitter (probably 5-20 microseconds at most; depends on drivers, interrupt configuration, etc.). Anything that Both Firewire and PCI will be

2) is the nature of MIDI DIN. If you stuff too much data over the wire too fast -- you will get "MIDI logjam" effects, a.k.a. smearing. This happens if you do something like send lots of tightly-packed controller messages. It happens because MIDI DIN can only send 1 byte of data every 320 microseconds - period. Try to send more, and data will just queue up until the logjam clears. This "smears" the timing. Note that USB MIDI is *not* susceptible to MIDI logjam effects in quite the same way, because it doesn't have a built-in throttle limiting data transfer to 1 byte every 320 microseconds. However, this is only true when the USB MIDI -- does not have MIDI DIN jacks. If you are using USB MIDI to send data to/from MIDI DIN jacks (as opposed to a hardware synth with a USB interface) --- then MIDI logjam can still occur, even with USB MIDI.

3) The final MIDI jitter source is the infamous 1 millisecond Windows "MM" timer, which sequencers have historically used for timing MIDI data.

---

OK. Time to explain how it's possible (in theory, at least) to avoid the 1 millisecond quantizing/jitter effects.

First, use a PCI-based MIDI interface - not USB MIDI. This removes one major potential jitter source.

Then - don't use the "MM" timer to time incoming and outgoing MIDI data. This part requires kernel-level coding, but should be doable.

The standard Windows API calls for sending and receiving MIDI do not actually use the MM timer directly. I know some posts have said they do - but those posts were wrong. For example, the API call for sending a single MIDI 'short" message looks something like midiOut(driverHandle,midiMessageData). There is no timestamp argument in that API call. Instead, Windows tries to send the data "as fast as possible" through the MIDI driver specified by 'driverHandle'.

If you call 'midiOut' from user-level code, then it can take a while for MIDI data to actually get sent out the MIDI DIN jack (Windows has to do a context switch from user to kernel level; various kinds of house-keeping may occur....). But, if you call midiOut from your own kernel-level code, sending MIDI data can be much more 'immediate' - especially if you bypass some of the normal Windows 'wrapping' of MIDI drivers, and tickle the driver more directly. Plus, if you are running kernel-level sequencer code - you can completely avoid using the 1 millisecond-resolution MM timer. What do you use instead? A higher-resolution, kernel-level timer (several kinds are available, Google on QueryPerformanceCounter for one option).

Putting all these pieces together --- a clever sequencer designer might be able to build a kernel-level 'event engine' that a) runs at kernel level, to avoid various layers of Windows cruft; b) talks to the MIDI interface drivers more directly, to bypass still more cruft; c) uses its own custom-shop high-performance timer, rather than the stock 'MM timer.
Easy? No. But it might be do-able.
Does Sonar do this? No. Noel said (later in this thread) that Sonar uses the "MM' timer.
Have I built code like this? No. All my sequencer engines were user-level stuff (lthe last one was Win98-vintage).
Will this make a different with USB MIDI drivers? Probably not. USB introduces enough other slop that it wouldn't be worth it.
How about Firewire? Possible, but more tricky to do than with PCI-based MIDI ports (because of the Firewire driver stack).
My gut tells me that a PCI-based interface still provides the best shot at minimizing jitter, because it has the lowest inherent 'transport jitter' (PCI bus is very very fast) and also has the simplest driver stack (less chance for Windows to muck things up).

Whew! If you plowed through all that, you probably deserve a beer

- Jim

Edit: Noel clarified that Sonar doesn't use a kernel-level event engine. Frankly, building one would be a pretty tricky piece of coding. It would be even more tricky to make this hypothetical 'kernel-level event engine' perform reliably, given all the other stuff that goes on in the kernel. Probably wiser not to go there...

"The difference between theory and practice in theory is much less than the difference between theory and practice in practice." [Randal L. Schwartz]

ORIGINAL: Jim Wright

My gut tells me that a PCI-based interface still provides the best shot at minimizing jitter, because it has the lowest inherent 'transport jitter' (PCI bus is very very fast) and also has the simplest driver stack (less chance for Windows to muck things up).

Whew! If you plowed through all that, you probably deserve a beer

- Jim

Excellent post Jim.
I agree on a gut level about the pci bus, remembering the first few USB midi devices and all of the discussion about the same type of issues kind of engraved it on a stone wall, in my mind at least.

Exactly. Internally SONAR always internally operates and stores MIDI at 960PPQ. This is by design since SONAR 1 I think. The PPQ setting in the project is only for display and edit purposes.

Thanks for the clarification, Noel. Guess we should have gone to you first!

Noel, I don't suppose there is any chance you can tell us what timers are used for retrieving midi data from the midi driver or whether Sonar uses kernel mode stuff of its own to timestamp incoming midi?

ORIGINAL: brundlefly
What you're saying is kind of what we all thought/expected. But this is not what I'm seeing in my testing. Ignoring for the moment whether a given transient starts right on the beat or not, if what you say is true, the beginnings of transients should be at even intervals (i.e. all early or late by the same amount. But I am seeing differences on the order of 100 samples from the expected interval between consecutive events when rendering through the TTS-1. I just did a test with the Dreamstation DXi, and got smaller errors, on the order of 30 samples. So it seems to be Synth-specific. I have not yet tried a VST instrument.

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.

 Sample Position       Interval
         0	
      1297	        1297
      2703	        1406
      4111	        1408
      5519	        1408
      6801	        1282
      8207	        1406
      9615	        1408
     11023	        1408
     12305	        1282
     13711	        1406
     15119	        1408
     16527	        1408
     17809	        1282

I then re-ran the test, this time using Twonar, which as Noel has mentioned is a very simple DXi included as a sample with the SDK. As you can see from the results, jitter disappears entirely in this case.

 Sample Position	      Interval
         0	
      1379	        1379
      2757	        1378
      4135	        1378
      5514	        1379
      6892	        1378
      8270	        1378
      9648	        1378
     11026	        1378
     12404	        1378
     13782	        1378
     15160	        1378
     16539	        1379
     17917	        1378

You can download Twonar here if you want to check it out. I think this shows fairly definitively that the problem is not in SONAR itself. We'll take a look at TTS-1 and see if anything can be done about the way it responds.