speed/latency of USB vs. Serial Midi Interface?

[spunkywinkerbean]

Will I notice a big improvement if I switch to a new USB midi interface instead of using my opcode studio 4? More voices? Tighter drums?

[RABid]

Right now there is a debate that USB Midi is actually more sluggish than serial. The quality of the unit may have more effect than the connection, but all other things equal serial may be better than USB.

 

Robert

[spunkywinkerbean]

Aaargh! So what is the fastest, most responsive way to hook up midi stuff to a new mac?

 

I have a feeling that a lot of latency issues comes from people running audio over the USB at the same time as MIDI?

[RABid]

My MTP/AV seems to have both USB and a Mac only RS-422 jack. You might study it to see if it will do what you want. It may be a bit expensive as MIDI devices go but I love mine.

 

Robert

[Rod S]

I've had good luck with a midisport 2x2 (USB), which everyone seems to have problems with. I'm not sure why it works wonders for some and is horrible for others. I will say this, it's the only USB thing hooked up. I'm on a PC though.

 

How bad of a problem is it? Midi has a limited bandwidth, and if you have a midi choke problem, a better interface may not help you.

 

I guess the only is to try it. Just order it from somewhere that has a return policy, and do some bench marking.

[Steven Denike]

Worthwhile to note that some software manufacturers have complementary USB Midi-Faces with 'poured in' logic, so , for instance,

 

Steinberg's MIDEX-8 works superiorly with Cubase/Nuendo

 

MOTU's MTP thingie works excellently with their own Digital Performer

 

ProTools has its own 10-channel interface;

 

I guess that one works with Logic as well . . .

 

If you have one platform you use, check out what the manufacturer offers . . . note that they don't interchange, though --> using a Midex 3 or 8 with Logic Audio or SawStudio will be just as laggy as something without the proprietary architecture.

[erpeewee]

aren't there any firewire midi interfaces on the market ? that should be fast enough.

 

ronald

[Dan South]

Originally posted by spunkywinkerbean:

Will I notice a big improvement if I switch to a new USB midi interface instead of using my opcode studio 4? More voices? Tighter drums?

You WILL see an improvement if you use an interface that's designed to work with your software. I'm using an Emagic amt8 with Logic, and the timing is amazing. If you use Cubase, consider a Midex; for DP, an MTP-AV. Each of these manufacturers has created a system of packet timing verification to compensate for inherent USB timing issues.

 

What sequencer are you using and on what platform?

[spunkywinkerbean]

I'm using OPCODE VISION. Am I screwed or what? I've been using the sequencer in REASON more lately for fun jobs... but I'm thinking about making the switch to Logic... your description of the timing just got me a little, ahem, excited.

[Dan South]

Originally posted by spunkywinkerbean:

I'm using OPCODE VISION. Am I screwed or what? I've been using the sequencer in REASON more lately for fun jobs... but I'm thinking about making the switch to Logic... your description of the timing just got me a little, ahem, excited.

Spunky,

 

I was a Vision user. I switched to Logic after the fall of the house of Opcode. Logic is SO much better! I thank Gibson on a daily basis.

 

I've written some quick start Logic tips on the Frangioni forum for people who had trouble getting started with Logic. (One guy had the MIDI port disabled on his keyboard.) Logic isn't difficult, but it's structured differently from Vision, so it might seem confusing at first. It took me about a week to get comfortable with it, but that was because I was trying to use an Opcode Studio 5LX interface which (I didn't know) was renowned for not working with competitors' sequencers. When I hooked up and amt8, everything worked beautifully.

 

Please look up the tips I posted over on DF's forum and by all means, feel free to contact me if you decide to go the Logic route. Logic just FLIES when you get into it, but it's helpful to have someone who knows the program show you the ropes in the beginning.

[soapbox]

spunkywinkerbean, as great as Studio Vision was, you'll find that the other sequencer choices are now a generation ahead of where Vision used to be. As mentioned above, one of the ways everyone has progressed is that each manufacturer now offers a USB MIDI interface that has especially tight timing with its own sequencer.

 

While I don't doubt that what Dan South says is true about Logic's timing using an Emagic amt8, I also believe you'll find similar tightness using any of the combinations mentioned by Dan and Steven Denike (as Dan implied).

 

Logic has a lot going for it though, not the least of which is the combined power of Logic Control and Logic 5. Its only competition in this respect comes at ten times the price, by using ProTools with ProControl. On the other hand, MOTU has recently incorporated a lot of Vision features into Digital Performer, so DP might be a comfortable fit for a Vision user. It also will have unlimited undo and an undo history in its imminent 3.1 release. Another option is Cubase VST 5.1, which now has VST link going for it, allowing users to connect as many Macs and/or PCs together as needed. This creates, in effect, a "super computer" able to handle as many tracks, effects, and VSTis as desired. Finally, if you have bucks, ProTools HD is the only platform to offer 192 kHz support and hardware. Of course, each of these programs has many more strengths than could be adequately discussed here.

 

IMHO, it's worth your time to see which DAW best fits your needs before jumping ship. However, I think you'll be missing out if you stay too long with Vision. As long as you continue to use Vision, I strongly recommend that you avoid using it with a USB MIDI interface. OMS (required by Vision) has not been updated since before USB MIDI interfaces were first released. Therefore, using Vision with such an interface is an invitation for trouble.

 

If you buy a new Mac to use with Vision, you might be able to stick with your Opcode Studio 4 and buy a Griffin gPort. The gPort is a serial port that connects to a G4 modem port in place of its modem. That may work for you until you choose a new DAW and MIDI interface (providing of course that Vision even works with OS 9, the minimum OS required to run a new Mac).

 

My two copper Lincolns,

 

Geoff

 

P.S. Obviously, there are valid options for the PC as well, if you're so inclined. My experience is mostly with the Mac platform, so I've limited my comments to what is available for Macs.

[Allan Speers]

Well, midi is still midi.

 

The "packet" type of hardware-specific mdid-implimentation that is described above by several posters will only improve midi transmission when using multiple channels at once. This is definitely a good thing, but there is still the issue of basic midi lag.

 

I have been trying to find out more about this myself. When the Mac first went usb, it was common knowlegde that usb had serious drawbacks for midi. see http://www.hinton.demon.co.uk/mac/macmidi.html

-a bit out of date, unfortunately.

 

Now it seems that everyone feels usb is ok. Didi it get better, or have companies just accepted it as the only easy answer?

 

Mega-Wolf used to make an interesting serial-pci card.

see http://www.megawolf.com/megawolf.html

 

Supposedly, this gave a faster connection to the pci bus. Is this no longer a viable (or needed) solution? It would require a serial interface to be attached to it, so I suppose its a non-issue..

 

On the pc, it is clearly better to use a pci audio-card with built-in midi than to use an add-on serial midi port. Why would the Mac be different?

 

So, what ABOUT a firewire interface?

Or a pci-usb card?

[soapbox]

Allan, thanks for the link. What it says makes sense. At the same time, MOTU's description of it\'s own MIDI Time Stamping technology claims vastly superior results:

 

"MTS delivers MIDI data from Digital Performer to synthesizers, samplers, drum machines and other MIDI devices with sub-millisecond timing accuracy - as accurately as a third of a millisecond for every single MIDI event...

 

...MTS achieves sub-millisecond timing accuracy on every MIDI data event, not just on some notes, some of the time..."

 

How do they do it? They don't say. Are their claims BS? I don't know. FWIW, a MOTU rep I talked to at Winter NAMM 2002 claimed that OS X (version 10.1) solves the workarounds that manufactures have had to do in order to accommodate USB's flaws.

 

I guess we'll see...

[RABid]

So where does this leave Sonar users? Cakewalk does not make a MIDI interface.

 

Robert

[BassGuy]

Allan, MIDI over firewire is available: search for Yamaha's mLan line. I haven't been able to get a straight answer about whether they are licensing this spec to other manufacturers.

 

Much as I hate Gibson's destruction of Vision (my sequencer of choice for a decade), I do think their GMICS spec looked like a good approach. Of course nothing has come of that spec years after it was supposed to have taken the world by storm.

[Pat Azzarello]

Originally posted by Rabid:

So where does this leave Sonar users? Cakewalk does not make a MIDI interface.

 

Robert

I'm a Sonar user too, and I'd like to see them jump on the timestamping bandwagon I've been using a USB MIDISport since I moved over to XP Pro (couldn't use my Opcode 64x because there were no drivers... arghh). I have noticed some timing weirdness (never had a problem with the Opcode serial device), but I'm still experimenting. As far as I can tell, Sonar 2 is not doing anything with timestamping (and I don't think MIDIMan is either).

 

DISCLAIMER: OK, I'm a software industry guy, but I'm not a USB expert by any means. From what I've read and people I've talked to I think I can summarize some of the USB MIDI interface arguments.

 

USB is a shared bus, so if you have a bunch of devices hanging off of it (especially devices that are constantly scanning/polling for input) it could affect timing. That's why timestamping technology so important if you really want to lock your performance in. It basically "guarantees" that the MIDI information exits the MIDI ports when it's supposed to - it doesn't get "set aside" when other information comes down the same bus. Bascically it's "reading ahead", sending the information to the interface with instructions to exectue at a particular moment in time, and moving on. It doesn't do alot for you "live", but playback is much more accurate.

 

BTW - I actually bought a new motherboard recently, and I'm trying to figure out if the additional USB connectors are using the same USB bus, or if they are independent (which would be much better). If it's the latter I'll dedicate one USB bus to MIDI only. I'll post again when I get a chance to check out the differences.

[Rod S]

Originally posted by BassGuy:

Allan, MIDI over firewire is available: search for Yamaha's mLan line. I haven't been able to get a straight answer about whether they are licensing this spec to other manufacturers.

Has this stuff actually been released? They've announced the mlan expansion for their synths (s80, cs6x, etc) a while ago... still nothing, AFAIK.

 

It will be cool once if this stuff takes off.. if and when.

[Dan South]

Originally posted by Allan Speers:

Well, midi is still midi.

 

The "packet" type of hardware-specific mdid-implimentation that is described above by several posters will only improve midi transmission when using multiple channels at once. This is definitely a good thing, but there is still the issue of basic midi lag.

 

This topic has been hotly debated for, well, forever. My take on it is that MIDI (the protocol) is still faster than the reaction of the devices that it's controlling. In other words, you can send notes to a synth faster than the synth's CPU can actually play them. So MIDI is not the bottleneck that some might imagine.

 

I'm currently working on a fast drum and bass style groove. I have simultaneous, extremely hectic drum parts playing on an EXS24 sampler (inside Logic, sample accurate timing) and a Triton (MIDI). I can't hear ANY lag, whatsover, and that's a lot of notes, PLUS all of the other MIDI tracks (synths, electric piano, a really hyper bass line, etc.). When I finish the song (hopefully in a couple of weeks), I'll post it on the Let's Hear It! thread, and you guys can be the judge.

 

These USB MIDI-timing enhancements (regardless of manufacturer) are for real. If I were to guess, I'm betting that they're using some soft of feedback of timing date, i.e. the computer sends MIDI out to the interface, and the interface sends back information on when the packets arrive. The computer compares the two and makes adjustments on the fly to keep the stream consistent. Again, this is just a guess, but however they've engineered it, it seems to work beyond the point where MY ears can hear any lag.

[Allan Speers]

".... MIDI (the protocol) is still faster than the reaction of the devices that it's controlling. In other words, you can send notes to a synth faster than the synth's CPU can actually play them."

 

-Not true. The basic midi lag, due to it being serial, is around 7/10th of a ms per note, plus about 1/2 ms additional for the whole transmission (per channel) therefore, if you send four simultaneous hits to your drum module at once, there would be a spread fo over 3 ms. -and that's on top of the processor lag and the OMS/Free-Midi lag. no "packet' technology can reduce this. Personally, I can hear a 3-4 ms shift in my hats track quite easily.

 

I'm betting that they're using some soft of feedback of timing date, i.e. the computer sends MIDI out to the

interface, and the interface sends back information on when the packets arrive. The computer compares the two and makes adjustments on the fly to keep the stream consistent."

 

-Clever idea, but VERY unlikely. That would keep all the hits in proper relation to each other, but the groove itself would be wobbling all over the place. AND, that would induce even more overall delay. besides, Neither Emagic nor MOTU mentions anything like this in their tech info.

 

"however they've engineered it, it seems to work beyond the point where MY ears can hear any lag."

 

-Not MY ears. I'm using Logic and the amt8. I'm quite picky about groove-timing, and we are FAR from there yet. Either the midi baud-rate needs to go up, or we need a parallel interface.

 

Does NO-ONE have any info on the current viability of MegaWolf?

[RABid]

Are you sure the slop in your sound source is not the source of your problem? Every step in the process adds latency, including sound generation and effects.

 

Robert

[Byrdman]

Originally posted by Allan Speers:

".... MIDI (the protocol) is still faster than the reaction of the devices that it's controlling. In other words, you can send notes to a synth faster than the synth's CPU can actually play them."

 

-Not true. The basic midi lag, due to it being serial, is around 7/10th of a ms per note, plus about 1/2 ms additional for the whole transmission (per channel) therefore, if you send four simultaneous hits to your drum module at once, there would be a spread fo over 3 ms. -and that's on top of the processor lag and the OMS/Free-Midi lag. no "packet' technology can reduce this. Personally, I can hear a 3-4 ms shift in my hats track quite easily.

 

A couple of remarks.

 

First the 3-4 ms being enough to be audible. I did some experiments myself and know that changing where notes fell by 12 ms was enough to take a groove that felt "tight" and turn it into a groove that felt lame. So the audible resolution is certainly smaller than 12 ms. The 3-4 ms seems plausible. Note that I was not measuring "just audible" but rather "clearly audible" as 12 ms.

 

Second, standard MIDI transport layer is about 44Kbaud which translates into 0.25 ms per byte or roughly half a ms for a two byte message.

 

So, actually sending single notes is not a problem. However, if you are sending 20 notes at the same time you have a big problem .

 

But a bigger problem is clocking accuracy of your computer. If your machine is doing a lot of IO (recording sound at the same time for example, or even updating the screen) a midi event can sit in the serial buffer for several milliseconds before being retrieved. Interestingly enough though, the midi events can actually appear to arrive early because the clock interrupt can be delayed as well! On input this will make things appear to arrive early and on play back it will cause them to come out late.

 

The way to avoid this is to have all time stamping done by the midi interface itself. On input this requires a special driver and the software (if MSDOS) has to not override this time stamping (its an option when you open the midi stream). On output you need a special interface to the midi device to allow you to send time stampong information.

[Dan South]

-Not true. The basic midi lag, due to it being serial, is around 7/10th of a ms per note, plus about 1/2 ms additional for the whole transmission (per channel) therefore, if you send four simultaneous hits to your drum module at once, there would be a spread fo over 3 ms. -and that's on top of the processor lag and the OMS/Free-Midi lag. no "packet' technology can reduce this. Personally, I can hear a 3-4 ms shift in my hats track quite easily.

 

And you can't compensate for that? Show me a live drummer who's consistently accurate to within three milliseconds, measure after measure, hit after hit.

 

>I'm betting that they're using some soft of feedback of timing date, i.e. the computer sends MIDI out to the

interface, and the interface sends back information on when the packets arrive. The computer compares the two and makes adjustments on the fly to keep the stream consistent."

 

-Clever idea, but VERY unlikely. That would keep all the hits in proper relation to each other, but the groove itself would be wobbling all over the place. AND, that would induce even more overall delay. besides, Neither Emagic nor MOTU mentions anything like this in their tech info.

 

I think it's extremely likely. Feedback is at the heart of nearly all process control mechanisms. The interface has a small buffer and a way to receive clock signals (outside the scope of MIDI) from the computer. These signals dictate when the notes in the buffer should be played. Either the interface has a clock to ensure that this is what happens (maybe), or timing information is fed back to the CPU to make sure that it the interface stays in sync (more likely). Of course, if the engineers at Steinberg, Emagic, or MOTU want to chime in, I'm all ears.

 

>"however they've engineered it, it seems to work beyond the point where MY ears can hear any lag."

 

-Not MY ears. I'm using Logic and the amt8. I'm quite picky about groove-timing, and we are FAR from there yet. Either the midi baud-rate needs to go up, or we need a parallel interface.

 

Well, then I guess you need to record parts one note at a time into your recorder and hope for better latency specs there. What computer are you using, BTW?

 

The amt8 IS a parallel MIDI interface. The data stream over USB (serial, but much faster than MIDI), is spread across up to eight parallel MIDI streams.

 

It took me years of trial and error to get it down, but I'm pretty happy with my MIDI grooves. Nobody seems to complain about the timing. I listen to my mixes, and I can't hear a problem with the groove, and I've usually got a LOT of MIDI tracks going simultaneously. Now, granted, the stuff I was doing seven or eight year ago sucked, but that wasn't MIDI's fault. It's because I had a lot to learn about groove.

 

Can the technology be improved? I'm sure it can. Can the current state of the art deliver a musical performance? Absolutely! Is MIDI an easy scapegoat for imperfect chops, bad arrangements, or inept programming? You bet it is!

[Allan Speers]

Byrdman,

 

"the 3-4 ms being enough to be audible. I did some experiments myself...12 ms was enough... The 3-4 ms seems plausible."

 

In fact, I have a drummer-client who can hear a 2ms shift on a drumtrack. Every time. I try to sneak in a 1-2 ms bump here and there (protools) and he always catches me.

On vocals, I find 5-10 ms to be about the smallest bump I can hear. 10 ms for SURE.

-----------------------------

 

"standard MIDI transport layer is about 44Kbaud which translates into 0.25 ms per byte or roughly half a ms for a two byte message. So, actually sending single notes is not a problem."

 

I agree that single notes are not the problem, since there is no slop, but for the record:

 

The midi-spec is MIDI serial data flows at the rate of 31.25 kilobits per second (baud) which translates into 0.32 ms.

 

A midi note-on 'event' consists of 3 words.

 

The first gives the note-on command and midi channel, the second gives the midi note (0-127) and the third gives the note velocity. If the system is using 'running-status' mode then future midi note events only require 2 words, the note and the velocity.

 

This can continue until a new midi event occurs e.g. note-off , control command, pitch command etc. So

 

The quickest 5 notes could be transmitted would be: 3x320uS + 2x 320uS + 2x320uS +2x 320uS + 2x320uS = 11 x 320uS = 3520uS

total: 3.52mS.

 

-My thanks to Tom Scarff for giving me this info long ago.

===================================

 

"If your machine is doing a lot of IO (recording sound at the same time for example,) a midi event can sit in the serial buffer for several milliseconds before being retrieved."

 

-Absolutely. Protools seems to be MUCH worse at this than Logic, for some reason. Logic may be much better in the future: Since Logic is dual-cpu compatable, I assumed that audio was running on one processor and midi on the other. not true! The second processor is only used for plug-ins. Currently, the only way to have REALLY tight timing is to use a seperate computer just for the sequencer. I know of several composers that use a second Mac, via ethernet, jsut for Logic-midi, with Protools on the main Mac.

--------------------

".... a midi event can sit in the serial buffer for several milliseconds before being retrieved. The way to avoid this is to have all time stamping done by the midi interface itself."

 

Here's where I must challenge you. How does a packet system solve this problem? I suppose that all data could be equally delayed, so that at least there's no slop. then you could do some kind of track-shift. Workable, though not optimum.

 

Even so, this will not correct slop on a PER-CHANNEL basis. If you send five notes on ONE CHANNEL concurrently (totally plausable) the packet-systems can't correct the inherent slop, as outlined above. It will still be about 4 ms, and will be random.

 

Then there's the delay caused by the interface itself. Again, regardless of packet-technology, this must cause further delay. Probably not more SLOP, at least. My earlier post concerns minimizing this HARDWARE delay. Just how bad is it? It's faster serial (thanks, Dan) but how much faster and is the implementation correct? Why was the early USB so bad for midi, and if that's been corrected, how? And again, would a direct-to-pci bus card (Megawolf) be significantly faster?

 

Midi as a whole is so bad that we must look for little improvements wherever they can be found.

[Allan Speers]

Hey, Dan.

 

Regarding "if you send four simultaneous hits to your drum module at once, there would be a spread of over 3 ms." you wrote:

 

-And you can't compensate for that? Show me a live drummer who's consistently accurate to within three

milliseconds, measure after measure, hit after hit."

 

No, I can't compensate for that, and neither can you because that delay is RANDOM. It's slop. And it's 3 ms in either direction, which puts that hat anywhere within a SIX ms spread. I know several good drummers who can lay down a tighter groove than that. I'm positive, because I've studiedd their (audio) grooves in Protools many times.

---------------------------

Re my guess that feedback is not emplyed, you wrote,

 

"I think it's extremely likely. Feedback is at the heart of nearly all process control mechanisms."

 

Well, maybe you're right there, since that feedback doesn't have to travel on the midi cable.

That STILL doesn't negate the per-channel slop, but I see now how it WOULD improve the overall groove accuracy. Good point. I still want to minimize overall delay, however: Even if the packet-idea maintains channel-to-channel timing integrity, there would still be delay. This could be compensated, but not while you're RECORDINg another midi-track. (same problem as dsp-delay compensation.)

------------

 

"I guess you need to record parts one note at a time into your recorder and hope for better latency specs there. What computer are you using, BTW?"

 

Yep, that's what I do (one CHANNEL at a time.) Far from perfect, though.

------------------------

 

"Of course, if the engineers at Steinberg, Emagic, or MOTU want to chime in, I'm all ears."

 

Me too! Think they read these forums?

[RABid]

If you want tighter timing go back a few issues and read the BT interview. Make adjustments at the wave file level once things are recorded. That also helps to compensate for latency of a track going through effects and various recording processes. Just don't over do it because you can sound a bit too processed, which can take the life out of the rhythm.

 

Robert