I said this a few posts ago - think about 120BPM - set it as a quarter note click. Now think about each click being divided into 96 parts. I think you'd be hard pressed to be able to discern anything much finer. Not that I'm complaining about the higher PPQs. I remember when DP first came out at 480PPQ. And so on. What are we up to now, like 4800PPQ or something? But who cares? If the operating system (Windows or Mac) and other software is introducing anomalies into the stability of the MIDI output, then who cares how many PPQs the system is resolving at? It doesn't matter because the whole system is unstable. I think that's what we've been talking about throughout this whole thread.

By the way, I haven't tried it, but from the videos and audio demos, the Roland MV-8800 is a really tight and funky feeling workstation (hardware). I don't know what it clocks out at, but it's most likely very stable at dealing with MIDI. It will be interesting to see where Roland goes with the linear audio + MIDI hardware solutions they've been producing. They're due for something new at this coming Winter's NAMM. Right now the Fantom-X keyboards and the MV-8800 record both linear audio and MIDI. I think they're the only hardware rompler workstation manufacturer to be producing this format.

The feedback I'm hearing is that a lot of that is going away as people are moving to using tools like Reason and Guru and satisfied with the results. You can find an MC-808 groovebox, the latest from Roland, on ebay for under $600 these days.

ORIGINAL: pianodano

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.

I wonder if this is a Fast Bounce issue. Have you tried disabling Fast Bounce? Some plugins have audio artifacts or misplaced notes when you render with Fast Bounce; if you disable it and bounce in realtime the rendered audio is accurate. With BFD, for example, I have to engage the "B" (for Bounce) button in BFD's interface *and* disable Fast Bounce in SONAR if I want to know conclusively that my rendered audio will be accurate. If I forget either step, there's the potential for glitchy audio or notes that move. I have yet to see an explanation of why some softsynths are fine with Fast Bounce and some aren't, but maybe someone has the answer.

ORIGINAL: dewdman42

ORIGINAL: Jim Wright

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.

Yep. Seems like everyone gave up on that when most consumers decided that 1-2ms of jitter was acceptable. (shrug). hardware timestamping during record is the only way around XP and OSX limitations IMHO. Playback is another story, pretty difficult for external midi, but Sonar should absolutely be able to make sure that playback to softsynths during mixdown and freezing is 100% jitter free. Even playing back a project through softsynths should be jitter free as far as I'm concerned...if there are problems...then it must be related to various buffers and programming in Sonar that needs to be improved.

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

Yea. I have to say though, I have MOTU traveler and the midi is VERY latent compared to my MOTU parallel port interface. Probably not the fault of firewire, it probably has timestamping though.

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.

Yea, that would be nice.

In reference to your remark on Firewire/1394, as Jim has already mentioned, the 1394 protocol does not timestamp, however, it is an isochronous protocol which means the timing of packets is guaranteed, but delivery of every packet is not, so Firewire/1394 alone has no built-in fault tolerance--packets can be dropped without notification and the system will not resend lost packets, as in certain synchronous datacomm protocols. Firewire/1394 packets come at regular intervals which makes it an ideal protocol for sending time-critical data. The Firewire 800 / 1394b spec claims a max jitter rate of 1/3 ms, which should satisfy the most exacting of MIDI requirements.

Now, if our CPU can't get back to the Firewire/1394 driver in time to empty the input buffer, or gets preempted before it can refill Sonar's input buffer, we can hardly blame Firewire nor Sonar, but that's another issue.

ORIGINAL: pianodano
Jim,

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

Danny

Danny,

When I last looked (years back), MIDISports used the stock USB MIDI driver stack. They did not have any of the special driver tweaks that Edirol included in drivers for the UM-550 and similar vintage gear. So -- years back -- I would have assumed that MIDISports would have pretty mediocre timing performance. These days? I'm not sure what, if anything M-Audio has done to improve their drivers, or if M-Audio has possibly benefited from general improvements to the Windows XP USB MIDI driver stack. They might be ok now; I can't say. I do know that I'd try a MOTU product first (if the latency was ok; see dewdman42's post about latency with his MIDI Traveller) -- and then maybe an Edirol UM-880.

You might have wondered about the 'special Edirol driver tweaks' I mentioned. Roland/Edirol have long had a special relationship with Microsoft; Roland/Edirol and Microsoft basically cooked up USB MIDI together (other companies got involved very late in the game). To their credit, Edirol got very concerned after I presented hard evidence about timing problems with USB MIDI -- and their subsequent products have been reviewed (by Martin Walker) as having better performance.

The best 8-port MIDI interface I ever personally tested - was an 8-Port SE, made by Music Quest. It connected via parallel port, and had great latency and jitter. This was designed for Win98, but the earthvegaconnection guy developed a replacement Windows XP driver for it. So, if you can find one -- you could use it, in XP, with the replacement driver. See http://8portse.earthvegaconnection.com/index.html

Jim, that is good to know about the Edirol tweaks. As you say, we have no way to know what other USB midi interfaces have also done such tweaks to their USB drivers...INCLUDING, we don't know if the same tweaks have gone into the Microsoft USB driver.

I used to have an 8 Port SE and can you believe I sold it at some point at a pawn shop a long time ago for almost nothing because I thought it was outdated technology...ha ha. That earthvegaconnection guy provides DirectMusic based timing too it looks like...I think that depends on Sonar supporting it though, not sure.

One clarification, the MOTU traveler uses a single firewire connection to handle all audio and midi. I did feel the latency was poor. Could have been the audio as much as the midi. I am using a MOTU2408mk3 now which seems less latency because I can get away with lower buffer settings, I gain a few milliesconds that way. I never trusted the midi on that thing though. Now I am using MOTU MidiTimepiece(parallel) and it works great....I would have to measure to find out if there are timing issues. Feels solid.

Original: kwgm
... as Jim has already mentioned, the 1394 (Firewire) protocol does not timestamp, however, it is an isochronous protocol which means the timing of packets is guaranteed, but delivery of every packet is not, so Firewire/1394 alone has no built-in fault tolerance--packets can be dropped without notification and the system will not resend lost packets, as in certain synchronous datacomm protocols. Firewire/1394 packets come at regular intervals which makes it an ideal protocol for sending time-critical data. The Firewire 800 / 1394b spec claims a max jitter rate of 1/3 ms, which should satisfy the most exacting of MIDI requirements.

This is all true. It's worth noting -- that MIDI-DIN is also not fault-tolerant; if the cable is pulled out, MIDI events are just lost (never resent). Further, audio packets are sent by the same isochronous transport - and the ear is hugely sensitive to even brief dropouts in audio (Glitch city!). Therefore, Firewire / 1394 has been engineered to provide extremely low packet-loss rates, and in practice I am not worried at all that MIDI data will be lost because it's sent using a non-fault-tolerant protocol.

Now, if our CPU can't get back to the Firewire/1394 driver in time to empty the input buffer, or gets preempted before it can refill Sonar's input buffer, we can hardly blame Firewire nor Sonar, but that's another issue.

Yup. The only solutions for this are to either increase the buffer size (which increases latency) or to rework the driver and/or application architecture for faster turnaround, so that buffers don't overflow/underflow (which can be tricky, and may well require kernel-level magic, depending on how cooperative the OS is towards low-latency processing).

- Jim

Jim,

Thanks for the valuable info. And also thanks RTGraham and Dewdman42. Everyone else also.

I will try what you have suggested when bouncing Realguitar tracks. I have, the last year or so, been recording them to tape but that kind of defeats the purpose of midi. I was originally freezing to free up proscessing of course and could always revert.

It sure seems to be some extremely knowledgeable guys involved in this thread. Lets' hope something good comes of it.

dewdman42 - the earthvegaconnection guy also states that DirectMusic doesn't handle usually sysex correctly. He's got some evidence for the claim -- see http://earthvegaconnection.com/evc/products/miditest/index.html#sysex and various links he cites.

The DirectMusic/WinXP driver for the 8-PortSE apparently avoids these sysex problems....

- Jim

Yea. It also looks to me that Sonar may not be taking advantage of the DirectMusic driver in any case...so it may be a moot point for us. He infers that only cubase users are using DirectMusic drivers and everyone else is just using the MM timer. I actually had a few email back and forths with that guy a few years ago when I was researching midi programming and timers. Nice guy. I don't remember much about our discussion other than that I wished I had kept my 8PortSE. ha ha.