ORIGINAL: Jim Wright
It would be interesting to test the hardware sequencer built into the Korg M3 (480 ppqn resolution), but I don't think Korg will loan me one just for that....

How would one go about testing that, Jim? Is special testing equipment required? I'd like to test my Fantom which also has 480ppqn res.

Wow.
This conversation has become beyond my technical abilities. I need to study more.

Thanks for talking about this.

- zevo

Maybe all of this is why so many producers still sequence on MPCs, Roland MVs, Korg Workstations, etc...

What a shame that all of this progress in technology has actually contributed to MIDI timing becoming worse over the years. One cause: Most developers probably don't know what a "tight" record even sounds like. Maybe they need to go and (re)visit some of the golden days of tight studio-musician records, such as the later Steely Dan records, the Quincy Jones records, the Jay Graydon produced records. Those are just a few examples. Obviously there are many more from many eras. But those certainly represented a time when "time" was critical.

Thanks for the continued great input everyone! Hope I can find the time to read those articles. Hope even more that Cakewalk will turn their attention to MIDI timing for the next Sonar release.

When I first started using Sonar (Sonar 2), I had midi timing problems where midi timing would drift and midi wouldn't seem to play as exactly as I inputted the notes.

Now Sonar's midi timing seems fine to me. I can't tell a difference between Sonar and the MPC. Things I did:

1. Lowered my midi buffer to 100ms.

2. Kept my midi interface drivers updated (Motu midi xpress XT).

That's about it.


IMO, Midi timing seems to have improved to me. In the 90's my MPU 401 compatible interface had horrible timing problems. Never knew if it was the computer, software or interface though but I don't really think old computers or hardware sequencers is the answer.


On Sonar and Reason, midi timing is rock solid to me.

On Ableton Live and P5, I had timing problems on both. Minor timing problems on Live, some major problems on P5 though but I'm not sure if it has been fixed or not.

ORIGINAL: dstrenz

ORIGINAL: Jim Wright
It would be interesting to test the hardware sequencer built into the Korg M3 (480 ppqn resolution), but I don't think Korg will loan me one just for that....

How would one go about testing that, Jim? Is special testing equipment required? I'd like to test my Fantom which also has 480ppqn res.

Nothing special. Just have the OUTBOARD sequencer sync to Sonar. Have Sonar send midi clock or MTC or whatever your fantom recognizes. Check it's midi implementation chart on the last page of your manual (usually). Record on both seqencers at the same time. Then check for accuracy by looking at exactly what tick each sequencer recorded the part at. Maybe a little math involved with the different resolution. My Yamaha Tyros is 1920.

ORIGINAL: jlgrimes

but I don't really think old computers or hardware sequencers is the answer.

Yeah, if you think about it, the computing power in a circa 1989 MPC-60, still known to be one of the most solid hardware sequencers, must have been exponentially less than the dual/quad core PCs of today. Combined with the fact that MIDI is very lite on CPU cycles, it can't be the PCs themselves. It must be the software and the way MIDI is handled as part of all of the other housekeeping tasks an operating system must deal with on a millisecond to millisecond basis.

ORIGINAL: dstrenz

ORIGINAL: Jim Wright
It would be interesting to test the hardware sequencer built into the Korg M3 (480 ppqn resolution), but I don't think Korg will loan me one just for that....

How would one go about testing that, Jim? Is special testing equipment required? I'd like to test my Fantom which also has 480ppqn res.

This is off the top of my head, so might be wrong. Hopefully you'll get the general drift (ah, no pun intended).

pianodano is on the right track. As he suggested, have the outboard (Fantom) sequencer sync to Sonar (via MIDI clock, MTC, whatever).
Select a sharp, percussive sound on the Fantom (so you can see note attacks more easily).
- hook up the Fantom audio output to Sonar audio in 1; route to record as audio track 1.
- hook up the Fantom MIDI output to a Sonar MIDI Input

Now, enable MIDI record on the Fantom, MIDI and audio record in Sonar, and play. You should end up with a MIDI track in the phantom, and both MIDI and audio tracks in Sonar. Sonar audio track 1 contains the original Fantom audio output.

Now, reroute / move cables around so that the Fantom audio output is routed to Sonar audio track 2 (record enabled). Set up the Fantom to play back the sequence. Start Sonar playback from the top, and record the 'Fantom-sequenced' audio into Sonar audio track 2.

You can now compare the original Fantom output (on track 1) with the Fantom-sequenced audio (on track 2) and compare the two audio tracks to see how well the two parts line up. You might have to slide one track in order to get the first note to line up, but after that (if the Fantom sequencer had perfect timing), notes in the two audio tracks should line up perfectly. Look for the biggest difference in note-on timing between the two tracks -- that will give you, roughly, the peak jitter of the Fantom sequencer. With a 44.1K sample rate, each sample is a bit less than 23 microseconds in duration. So, if the same note occurs 10 samples later in one track, compared to the other -- that's about a 230 microsecond difference. If the first notes line up exactly (same audio sample) but later notes are skewed by up to, say, 200 samples -- then you have a max jitter of 200 * 22.6 microseconds, or about 4.5 milliseconds.

To check Sonar +MIDI interface timing, you can use the MIDI track your recorded during the first pass (Sonar MIDI track 1) and route that to your Fantom. Route the Fantom audio output to record on Sonar audio track 3. Start Sonar playback from the top, and record the Sonar-triggered Fantom audio (onto audio track 3). Now compare audio tracks 1, 2 and 3, to see how the Sonar-sequenced synth audio (track 3) compares with both the original live-performed Fantom audio (on track 1) and the Fantom-sequenced audio (on track 2). Again, you may have to offset one or more tracks to get the first notes to line up across all tracks. Then - look for the biggest differences between note onsets, later in the recording, and whip out your calculator.

OK. Again, that was just off the top of my head. To be sure, I'd have to try it, figure out what I got wrong, and fix things accordingly. So - don't take it as gospel!

Now - the above approach takes no special gear besides some cables. If you're willing to hack up a MIDI Thru box, you can convert MIDI-DIN current-loop signals into audio data. Then, you can record the MIDI -as audio - using a Sonar track -- and measure the actual timing of MIDI events, without having to go through the PC MIDI interface and possibly-wonky MIDI driver stack. (Sounds weird, but it works). See my paper (http://openmuse.org/noncpl/MIDIWAVE-ICMC2001.pdf ) for details.

Its not the hardware. Its the Operating system. If you have a custom built hardware box you can control every instruction that happens in real time and ensure the timing you want. In a multi-tasking operating system such as Windows XP, OSX, linux, etc... any software program that is running is sharing cpu time with other processes that have to do what they have to do. The OS provides timers, interrupts and other mechanisms to try to give software developers an opportunity to interject on demand and do what they need to do, but this is not exact or perfect control....and so even 1ms timing cannot be guaranteed on top of all the popular Operating Systems. A drastically faster CPU *MIGHT* reduce the contention of these various tasks which could theoretically improve the DAW's ability to make completely effective use of the multimedia timer...but this is not the main constraint.

Tangent:

It actually used to be possible with win98 to create tighter midi timing because there was a hackish backdoor that could be exploited in win98 to THUNK into a 16bit DLL, which had the fortunate byproduct of forcing that 16bit DLL to execute immediately. By this means midi programmers could force a midi driver to get attention and timestamp incoming midi events via the 16bit DLL....basically trumping anything else the OS or software was up to at the time. However, with the release of NT4 and Win2k, Windows became a more true multitasking 32bit OS and this back door capability was lost. In fact for a while, midi timing in NT and Win2k was absolutely terrible and people were sticking with Win98 for that reason. Microsoft eventually got Win2k working better and definitely they got XP working a *LOT* better...but its still probably not quite as rock solid accurate and tight as a properly and cleverly code Win98 application could be in terms of midi. Of course there are many other benefits to XP and true multi-tasking that far outweigh the less-then-optimal midi timer accuracy of XP. Plus, who wants to deal with Win98 crashing all the time?

Uncareful programming can result in much much worse than 1-2ms jitter actually. That is why Live is now being improved. IMHO, anything close to 1-2ms timing accuracy on XP or OSX is about as good as its gonna get on a DAW and not worth crying about any longer. If you want better, start crying to Microsoft and Apple, but I doubt they will ever change it in the OS because relatively speaking we are a small crowd.

I just spent a bit of time researching some hardware sequencers out there. Most all of them are 96 ppq, these are the ones purported to be rock solid timing. Ok...perhaps so,, rock solid, but 96PPQ is 5ms per tick at 120bpm. That is not exactly any better than the reports we are getting from some here about Sonar handling within 1-2ms of jitter at 960ppq. By the way, 960PPQ = 0.5ms per tick.

See what I mean? Are we looking for the wrong thing here in terms of the problems some people are reporting in Sonar midi timing?

I only found a few newer hardware sequencers like the Akai MPC-4000+ ($2800) and the Roland MC-909 which are 480ppq (1ms per tick and hopefully no jitter). Those are probably about the best there is right now, but not inexpensive. All the old ones and also most of the new ones are only 96ppq and personally I think if Sonar really is giving you 1-2ms of jitter at 960ppq, then Sonar will be tighter then those old hardware boxes...with one exception....a quantized performance would sound tighter on the 96ppq hardware box since every note would land exactly on a tick and have zero jitter, while sonar might float around on playback by 1-2ms...maybe?

However the stuff people have talked about so far as mattering are things which should not be quantized, so the old hardware boxes would not be any better than Sonar, in fact they would be worse. Sounds like the top of the line MPC or Roland groovebox might be better...but I sure can't afford one.

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.

>>... I don't really think old computers or hardware sequencers is the answer.

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.

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).

Lowest jitter - doesn't always drive my own purchasing decisions. I have an EMU 0404 USB interface, because audio quality (at the price) is excellent, the feature set suits my needs very well, and it's fairly low-jitter for a USB MIDI interface. I also have an Edirol UM-550. But, when I really obsess about MIDI timing - I hook a MIDI DIN output from my controller to the MIDI IN input on my EMU 1820M (PCI interface).

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.

- Jim

ORIGINAL: dewdman42

ORIGINAL: pianodano
For soft synths Realguitar, EWQLSO, Colossus, and others available here. I have taken Realguitar tracks, tweaked them to where they sound so realistic I could have sworn I was in Nashville, frozen the track and couldn't believe it was the same track playing (as in wth?).

Yikes, not good. That infers that Sonar is not handling midi to soft synths without jitter of some kind. Perhaps bugs in delay compensation? Not sure if the problem is happening while you're playing back the unfrozen midi tracks or if the problem happens when you free them. I would think that freezing should render perfect results..but if you can't hear it correctly while editing in the PRV..what difference does it make. They both need to be spot on and there is really no excuse for it not being so.

Certainly you can align any midi track in ppv if you want or need to. But it often looses the original (as played) feeling. What I see is it's the actual played part that is captured incorrectly. I am fairly confident it's not the clock in my case.

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.

ORIGINAL: Jim Wright

>>... I don't really think old computers or hardware sequencers is the answer.

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.

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).

Lowest jitter - doesn't always drive my own purchasing decisions. I have an EMU 0404 USB interface, because audio quality (at the price) is excellent, the feature set suits my needs very well, and it's fairly low-jitter for a USB MIDI interface. I also have an Edirol UM-550. But, when I really obsess about MIDI timing - I hook a MIDI DIN output from my controller to the MIDI IN input on my EMU 1820M (PCI interface).

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.

- Jim

Jim,

Any thoughts on midisport 8x8's ? They're USB.


Danny