your last comment about being sample accurate or not is interesting as relates to playback. None of the midi interfaces mentioned so far have any way to remain locked to the same clock that the audio is following. Usually they are based on some kind of atomic clock, say, number of milliseconds since 1970, or something like that..and its always dealing with offsets since the time it was started. Is that sample locked? No. However with a reasonable degree of accuracy....the playback can still be jitter free...as each midi event can theoretically be queued in the hardware and output on schedule according to an offset time from when it was started. It is up to the DAW software to "stamp" the midi events with the correct offset time to use, that matches up with what the audio is supposed to do with the current buffer settings, etc.. Anyway, that is in theory. The MPU was a long time ago..not exactly sure what smart mode was doing, but does not surprise me if there were problems getting sync'd with audio. But I thought the newer stuff from MOTU, Steinberg and Emagic worked all that out. Not sample locked per say, but still theoretically should have been jitter free.

Again, I would really like to hear more from Cakewalk on this issue, its something I've always wondered. These days I am playing back everything via VSTi's in any case, so to a certain degree...I don't care so much about the midi timestamping on output. However, when I hear that people are having problems with jitter while playing back through VSTi's, well that just makes my blood literally curl in paranoia...

Yep - and the odd thing is that my EZ drummer tracks played back perfectly, UNTIL I add EZPlayer on top to try out beats... Very odd... but all my other SoftSynths exhibit the problem, heck, even sending to my hardware Roland XP30 thru my MidiMan 8x8 had the stuttering...

Since EZ drummer has its own sequencer and goes directly to a sample playback engine..its not so surprising to me that it would play back perfectly....Toontrack can do any kind of optimizing they want inside EZDrummer and never have to post a midi event to send over a channel to anywhere, if you see what I mean. Yes, it reads a midifile to obtain a drum groove, but when its playing back, it does not have to rely on sending midi events through midi ports. However, I would be surprised if EZD is doing anything other than sending midi events to the same internal sample playback engine that handles incoming midi events from say EZplayer or sonar. So I don't know what to say there.

If Sonar is getting loosy goosy about how it routes midi events around inside itself through all the various virtual midi pathways that can be routed in Sonar...then that is a big problem. I hope that is not the case. So far I have not experienced problems like that in Sonar at all.

This has turned out to be an amazing thread. The only thing missing now is some input from Cakewalk reps. How 'bout it guys? Is it time to take a look at this?

what I play in is not what I hear back.

I can confirm that it certainly is an issue. As a wind synth player, I have to edit recorded MIDI. I'm throwing down a lot of data at once -- note, pitch bend, and breath control.

ORIGINAL: 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.

I would say that this is due to the fact that some softsynths can't handle such high buffer sizes... at extremely high latencies, some softsynths just start getting choppy, like what you're describing. However, the fact that it was happening when sending MIDI out to you Roland hardware unit (as you mention in another post) makes me wonder what else could be going on.

ORIGINAL: Nick P

<snip>
My theory (completely unscientific), is that as these software DAW applications have gotten more and more bloated, they put less and less emphasis on tight MIDI timing in the rush to "gold-plate" the application. This combined with how a computer's OS deals with incoming and outgoing data (handling multiple housekeeping chores at once, but still in the final analysis, one at a time, such as mouse moves, screen repaints, etc...) just begs for MIDI timing to be less than 100% accurate. And why should a manufacturer put emphasis on it? Many Sonar users in this forum seem to be guitarists or bassists who are just thrilled to have audio recording available outside of an expensive commercial recording studio. Many users have no idea what MIDI is, how long it's been around, or how it differs from audio recording (get Scott Garrigus' book).

All I know is that my ears hear the difference when MIDI is recorded and played back accurately, versus sloppily, and I am very happy to see that at least one software manufacturer has acknowledged this issue, and has apparently done something about it.

I wish Cakewalk would put aside their rush to audio nirvana for a minute and do some serious MIDI recording and playback tests - i.e. have a seasoned professional keyboardist record MIDI data in real time into Sonar and at the same time record the audio into Pro Tools or something similar. Now record the output of Sonar's MIDI playback from the sound source again into Pro Tools. Compare the timing of the 2 tracks at a high level of magnification. I think a difference would be easily perceptible.

(Edited for grammar/spelling)

At last. Someone else noticed.

We both started with midi at the beginning.

I have recorded to tape and Sonar at the same time. Sonar doesn't always reliably put it where it's played. Period. When I stated my results, some of the "experts" even went so far as to blame the tape recorder as being out of sync. LOL. I use a Timeline microlynx for sync - You can be sure the tape recorder is LOCKED.

ORIGINAL: RTGraham

I would say that this is due to the fact that some softsynths can't handle such high buffer sizes... at extremely high latencies, some softsynths just start getting choppy, like what you're describing. However, the fact that it was happening when sending MIDI out to you Roland hardware unit (as you mention in another post) makes me wonder what else could be going on.

Uhmm, how should the plugin care at all what the buffer sizes are? that is in Sonar's domain I think. No?

I am not a plugin programmer, so i can't speak authoritatively...but I think if the buffer is too small, then the plugins can be starved. If the buffer is too big the only consequence should be long latencies and the plugins shouldn't care at all..but there could be more to it than that I suppose.

So there are two seperate questions. PianoDano is talking about recording midi parts that are played on a midi controller and that he doesn't feel it is accurate. That is one half of the question. The other half is, if the notes are painstakenly edited to be exactly where they need to be, will sonar play them back through plugins, every time, as they are supposed to be, with rock solid timing..particularly during mixdown or track freeze?

JB,

It's not just Logic and the Mac, but any system using IEEE 1394/Firewire, for instance, Yamaha's mLAN and the host of other 1394a interfaces.

The IEEE 1394a spec (aka Firewire 400) reduces jitter to very low values--3ms if my memory is correct. The faster 1394b spec, supported by the Mac and few others at this time, claims much lower values.

Hmmm... Many opinions, few data points. I did quick test: Set up a MIDI track to send 96 note events at 10-tick intervals at 960 PPQ and 100BPM (.625ms/tick). Plugged a MIDI cable from the Out to the In on my M-Audio Omnistudio USB interface, and recorded the output of the test track. No synths or controllers were involved, just MIDI data making a silent round trip.

Average round-trip delay was 11.1 ticks = 7ms. Assuming delays are equally divided between sending events and clocking them back in, that means MIDI events recorded from a manually played hardware synth might get clocked in 3.5ms (5 ticks) late on average (not including delay between the keys and the MIDI Out on the controller). Not perfect, but I can live with it.

But here's the kicker: Standard deviation of the half-a-round-trip values was 0.5ms (less than 1 tick. So "jitter" is basically a non-issue in this test.

For reference, I ran the same test with the same setup at 96PPQ, giving 96 events at 1-tick intervals. Results were about the same within the limits of the lower resolution. Mean round-trip delay was about 0.9 ticks, and half of that is .45 ticks = 2.7ms, with a standard deviation of about 1ms.

In summary, it does not appear that jitter is a significant problem in this test configuration, and higher clock rates do not have a isgnifcant impact one way or the other. This makes sense, as even 960PPQ is extremely slow compared to system clocks running in the Gigahertz range with a 1000 or more CPU cycles going by between ticks.

I will say, however, like others, that I have had more trouble with MIDI timing errors in the Windows era than with the old MPU-401 hardware interfaces with their onboard clocks running under DOS. But I have always been able to fix these problems with configuration or hardware changes. Based on that experience, and the results of this (admittedly crude) test, I would say that anyone who can actually feel/hear a significant MIDI timing issue on his/her system probably has a system-specific configuration/performance problem that is not inherent in either the OS or the application.