ORIGINAL: Jim Wright
However, as others (dewdman42 ?) noted, the MOTU interfaces seem to be pretty high latency (10 milliseconds?) even though their jitter levels may be quite low (perhaps as low as 1/3 millisecond) . 10 milliseconds latency (lag, delay in hearing softsynth notes play live....) is borderline in my opinion.

- Jim

NO!

(MOTU hardware timestamping is called MTS by the way)

MOTU interfaces do not generally have high latency. The Traveler is the one I was complaining about..it is one of their firewire audio+midi interfaces. And I do not know if the latency was due to the audio over firewire, midi over firewire or both, but when I use a motu parallel midi interface together with motu PCi audio, the latency is much less. I read some reports that all firewire audio interfaces have a slight bit more latency than PCI pro audio cards, and that was enough for me to get rid of it and go back to PCI audio.

I never measured the midi latency of the MOTU usb midi interface with MTS, that I used to have, so I don't know how good or bad it was, but generally I have had mixed feelings about all usb midi interfaces, they make me nervous in general. But I would definitely definitely not declare that MOTU midi interfaces incur a 10ms midi latency!!!!!

I would say that most likely the current MOTU midi interfaces incur the same USB latency that other USB midi interfaces incur, except the MTS supposedly happens, but I do not know how Sonar synchronizes the timebase to make use of the MTS timestamp.

I know that Digital Performer does in some way, but the only answer from Noel on this so far is that Sonar will not ignore the timestamp if its there...but just exactly how the MOTU obtains a timebase for creating the timestamp, that is the part I don't understand....so I cannot declare yet that the MOTU midi interfaces with MTS actually take advantage of that feature in Sonar. I have a question in to MOTU about it also. still waiting for a response. I kind of expect their answer to be as vague and un-confirmational as Noel's. (shrug)

Sometimes I wish I had kept my MOTU USB interface, but I sold it to a buddy when he got OSX and needed it. I still have my parallel port motu midi interface. The reports are that the parallel port midi interfaces have the lowest inherent midi latency of all, and so that is why I decided to use it. It does not have MTS however. My hope is that its response is closer to 1ms than the USB one to the point that MTS is not really needed, but I will probably never really know for sure.

For the record, I think that anyone getting a consistent 2ms jitter from their midi interface, no matter what its made of, is fine. They don't need to worry about it. 2ms is good! But I mean, it must be consistent. There cannot be one single time that it jumps up to 5ms or worse. If its always within 2ms of jitter...I say stop worrying about it and play your music.

Just to put some perspective on what 2ms is. Sound travels through the air at approximately 1ft per millisecond. Ever play in a band? I guarantee you're ears were more than 2 feet away from the snare drum. just by moving around the stage you would have changed the time it takes for the snare drum to reach your ears...by several milliseconds. Granted, in that situation its generally a more stable delay..not jitter. But just to give some perspective on how little 2ms of delay really is. 10ms is noticeable though.

ORIGINAL: Jim Wright
The Sonar help is pretty clear that some plugins require a realtime bounce (such plugins don't work correctly during Fast Bounce).

That is something I did not know. I wonder why? Does anyone know the technical reason why a soft synth plugin would require a real time bounce to work correctly? This of course instills new timing paranoia into my soul. How will I ever know for sure if its ok to use fast bounce on all my plugins? The only way to feel safe would be to always use real time bounce! YUCK!

As far as a soft synth intentionally rendering every note 10ms(300samples) late...sure a soft synth could intentionally render every note 10ms late...on purpose, like in a slow attack. That is why for this test everybody should be using something that has a sharp attack, not a blatantly long attack.

I need to make a correction/clarification of what I reported earlier on this. I noted that AudioSnap was locating the TruePianos transient markers consistently 300 samples (actually about 6.8ms) behind the note-on. I mistakenly jumped to the conclusion (Bad dog!) that this had something to do with the buffer latency in my system. Well, I just looked really carefully at the wave, and manually picked out the transition from the decay of one note to the attack of the next, and found that it was only 50 samples (almost exactly 1 tick) late. So it appears that True Pianos is very close to right-on in both interval consistency, and absolute delay.

With the other synths, I did not rely so heavily on the AudioSnap transients, because they were clearly all over the place, so I still stand by my findings with regard to those synths in terms of their interval variability, but I would have to take a second look before drawing any definite conclusions about their absolute/average delay.

http://www.cakewalk.com/support/kb/kb2003151.asp

dewdman42 -- ok, fixed my post. Sorry I misremembered what you said.

As for why some plugins screw up when Fast Bound is used -- I can imagine a number of ways that a plugin could be miscoded -- but I don't know, not having written audio plugins.

Edit: removed speculations about how plugins might screw up during FastBounce. Noel pointed out that DirectX can run faster than realtime (thanks, Noel - I wasn't sure, but trust you to have it right). My other speculation seems dubious, reading it now - so I zapped it too.

Thanks for the analysis, Jim. Yes, the recap is exactly what I did. After doing it, I was converting ticks to milliseconds incorrectly and thought it was incredibly accurate. Now I realize that it's just about the same results I got using the Fantom USB driver.

Apparently the Fantom's USB driver supports DirectMusic but the EMU 1820m's midi ports do not. I discovered this by: Run Start|Run|DXDIAG. On the Music tab, select the emu midi port in the lower listbox (with the midi cables connected to the Fantom, of course), and hit the Test DirectMusic button. When I try that on the emu port 1, I hear nothing. But, selecting Fantom's USB interface, it works.

Right...but even if the Fantom USB supports the directMusic APi, I don't think that neccessarily means that Sonar is using it.

Jim,

Thanks for the link to the SOS article. Their discription seems a little ambiguous (wouldn't expect them to get too techno geeky in a mainstream review), but it sounds like FPT is more or less good. I'm interested to read the results of your tests with your Edirol gear. I've also got an RME Fireface800 connected to an FW400 PCIe card ... I wonder if using the FF's MIDI I/O for my keyboard would yield more accurate results.

Tested the RealGuitar. Took a while, because they definitely have some sort of randomizing algorithm that makes each attack a little different, which confused AudioSnap a little bit. It sounded funky on playback, too.

Quoting myself again, because I looked into this a little more. I Re-rendered RealGuitars using 16th-note intervals so that each note would decay to zero before the next, allowing me to see the initial transients with no overlap, and...

Well, well, well, those RealGuitar guys sure are sneaky. Turns out there are 6 or 7 distinct plucks sampled with differing attacks and amplitudes, which are played back pretty much in random order. I found this by rendering the audio twice, and comparing the results. Every once in a while, two transients would have the exact same delay, and when I zoomed in, I found that the waveforms were identical, sample for sample. But the 6 or 7 variations were never in the same order; sometime you'd get two or three of the same sample in a row, and sometimes you wouldn't see a particular sample for 9 or more notes.

Perhaps more relevant to this discussion, I also found that even the identical pluck samples didn't necessarily play back with the same delay. I observed differences in the timing of like plucks of up to 88 samples (2ms). It also seemed that some pluck samples were more likely to be very late than others. This might be because their attacks were longer.

The mean lateness, looking at the first deviation of the signal from dead zero was about 89 samples with a standard deviation of about 40 samples (< 1ms). Pretty reasonable, really, and probably just enough to humanize the sound a little without getting to the level of being sloppy.

Anyway, all this explains why inverting the rendered signal won't cancel out the real-time playback. No two "performances" of RealGuitar will be the same, due to this deliberate random variation.

ORIGINAL: dewdman42
Right...but even if the Fantom USB supports the directMusic APi, I don't think that neccessarily means that Sonar is using it.

You mean the timestamping capabilities, right? Considering your and Jim's description of the inaccuracy of usb itself, it's impossible to determine. I somehow doubt it just because Sonar has existed long before DirectMusic and they are probably using old code. BTW, reading up on DirectMusic, MS apparently dropped it for Vista 64, but it exists in Vista 32.