ORIGINAL: brundlefly

It remains to be seen whether TruePianos superior performance is inherent to VSTi technology or just that they've got a better timing algorithm. If someone can turn me onto a freeware, downloadable VSTi somewhere, even a short-term demo like the TruePianos installation I'm using, I'll test it.

You know things are bad when you start quoting yoursself. Oh well. This is just getting more and more interestinger...

Long story short: downloaded and installed Jamstix 2 Demo. I get some noise out of it, but not drum sounds, and it runs my CPU into the ground, so I gave up on it.

Instead, I re-ran the rendering timing test with the Roland Groove Synth, another DXi bundled with Sonar. As before, I used its Claves patch which has a really nice sharp attack and was easily picked up by AudioSnap. I got yet another behavior pattern, though similar to the TTS-1:

The first transient was 136 samples late; the second was 140 late, the third was 144 late, etc. So the interval was consistent, but was 4 samples too long. This went on until at the 25th event, the rendered transient was 232 samples late. But then on the next event, the interval dropped form 2944 to 2816, so the transient was only 108 samples late - i.e. better than where I started. Huh?

So, on a hunch, I scrolled ahead to find the next place where the interval dropped from 2944 to 2816. I found it, and what do you know, it's exactly 32 events later. So I went out another 32 events, and found the same thing: one transient 232 samples late, and the next one back to 108 samples late.

Now, as everyone knows, 32, being a power of 2 is one of the magic numbers in computing. When things happen at intervals of exactly a power of 2, you want to take a look at your programming. I once found a bug in an early Olympus digital camera driver that was creating a "hot" pixel at 64-pixel intervals. I reported it, and a couple of weeks later a new driver came out, and the hot pixels were gone.

But, 32 events also happen to be exactly half a measure in my test setup, so...?

Here you go.RealGUitar here : http://www.musiclab.com/downloads/trial/

Unfortunately it doesn't look like it has but 1 guitar in the demo (no stereo guitar)

ORIGINAL: brundlefly
I did exactly this to record Two-Dude Defense. A couple of tracks of drums, and a bar of horn played through the TTS-1, with piano played through TruePianos. I haven't analyzed it to the sample like we are here, but it sounded fine, both in real-time and rendered:

http://www.soundclick.com/bands/songInfo.cfm?bandID=757783&songID=5856598

Admittedly I wasn't putting that much load on the TTS-1. A bigger problem with the TTS-1 in my opinion is that it sounds little better than a cheap soundcard. It's handy for ginning up a quick arrangement, though.

Maybe it's improved since the last time I last tried it. I mentioned its odd timing here a year or two ago and recall that ModBod confirmed it. Knowing its history, it still wouldn't be my first choice to test midi timing though.

Here you go.RealGUitar here : http://www.musiclab.com/downloads/trial/

Unfortunately it doesn't look like it has but 1 guitar in the demo (no stereo guitar)

Why am I not surprised that the VSTi from the piano guys is spot-on, and the VSTi from the guitar guys is all over the dang place!

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. So I manually picked out the sample time of each transient as I've done before. But even so, the interval between transients was all over the place, pretty much at random, ranging from right on the expected value of 2940, to 2802 (138 samples = 3.1ms too short) to 3092 (152 samples = 3.4ms too long).

I should mention that these two extremes were adjacent intervals because things were cranking along at about 185 ±7 samples late (compared to the MIDI note-on time) when suddenly a real clam came along 330 samples late, making the first interval too long, and the next too short. In general, though, the variation was pretty evenly distributed across all possible values with no perceptable pattern as found in the DXis I tested.

So the bottom line in my view is that VSTis are not immune to this problem, but the good peformance of TruePianos shows that the problem most likely lies with the soft synths themselves, and not with Sonar, or the VSTi technology in general. Until I see a counter-example, however, the DXi technology is still suspect.

Dave

ORIGINAL: Noel Borthwick [Cakewalk]

Still havent read this thread closely, so I may be missing some arguments, but there are a lot of variables with softsynths that can cloud the test. e.g. depending on the patch the synth might render its audio later than the actual MIDI data, or it might not be deterministic for a test. Basically its up to the synth to decide when to actually start rendering the audio. The MIDI timestamp is the cue to begin rendering thats all.

The ideal test is to take a minimal synth that renders audio instaneously when it receives a note on. A test VST to just emit a test tone in response to a note on would be ideal for this test. The test DXi Twonar from the DXi SDK that Ron wrote years ago could be used to test this with DXi's.

Noel, doesn't delay compensation supposedly take care of this sort of thing?

I've only gotten through two pages of this interesting thread, but here is a quote from Edirol's description of their UM3-EX USB MIDI interface, which I currently use.

"The UM-3EX uses FPT (Fast Processing Technology) to ensure low-latency, low-jitter MIDI transmission, even with three devices daisy-chained together".

It doesn't look like it supports MIDI Timestamping ... I wonder what FPT really is. And here's a hardware manufacturer confirming MIDI jitter.

Thats not true. There is nothing to stop a synth from deliberately rendering audio late in response to a MIDI note. For example a patch with a very slow attack could intentionally render the audio much later than the start time of the MIDI note.

Thats not true. There is nothing to stop a synth from deliberately rendering audio late in response to a MIDI note. For example a patch with a very slow attack could intentionally render the audio much later than the start time of the MIDI note.

I think for the purposes of this discussion, we need to define delay as the time between the MIDI note-on, and the time the softsynth triggers the envelope for a sound, regardless of what that envelope looks like.

ORIGINAL: brundlefly

I think for the purposes of this discussion, we need to define delay as the time between the MIDI note-on, and the time the softsynth triggers the envelope for a sound, regardless of what that envelope looks like.

Yes, I agree with you here. The envelope is of no consequence, but Noel has a good point..there is nothing stopping a plugin from intentionally outputting a delay before starting the envelope. I don't know why any soft synth plugin would want to do that on purpose and right now I can't think of any examples of ones that would want to, but theoretically, its possible that you could have a soft synth the responds to a midi event by waiting some amount of time, then outputting a sound or series of sounds that are spaced apart however it feels like.

But like I said, I honestly can't think of any plugins that would want to do that on purpose. To me it seems like either (A) its a bug in the plugin or (B) the plugin is so complex that it simply can't output sound without some delay.

I was always under the impression that all plugins incur some amount of delay to do whatever they gotta do and that delay compensation would make up for it. granted, when playing a soft synth in real time, delay compensation doesn't really make sense, but while rendering a midi track it sure might make sense. but Noel says that plugins just don't require that much time except certain kind of plugins that do lookhead and stuff like that, but most DSP processing is so fast that delay and delay compensation is a moot point.

All this means, I guess, is that if there are bad output timing problems from a soft synth, then the soft synth is either designed to work that way or just plain buggy and there is nothing anyone can do about it other than avoid using that plugin.

Hi dstrenz --

To recap what you did:

• Record 4 bars quarter notes using a Fantom sequencer at 120 BPM
  
• Saved Fantom data as a SMF, and imported it into Sonar
  
• Played back Fantom data, and recorded it "live" into Sonar
  
• Compared the Fantom SMF data (imported into Sonar) with the "live" MIDI data (recorded by Sonar using an 1820M PCI-based MIDI interface)

The results showed maximum MIDI Jitter of 4 ticks (960 ppqn at 120BPM)

Using 960 ppqn at 120 BPM, 1 tick is equivalent about 0.521 milliseconds (0.520833333.... rounded up).

A maximum error of 4 ticks translates to about 2.1 milliseconds peak jitter.

That's not really surprising (although I'd like it to be better). If the EMU MIDI driver uses the 1-milllisecond Windows system clock as the time reference, 2 milliseconds peak jitter is pretty good, actually. The only way to get really lower jitter numbers is to use a higher-resolution timebase. (DirectMusic APIs can support a much higher-res timebase, but I don't know if the EMU card is using them - or what the EMU card might use as a timebase.). Also - consider that a 3-byte MIDI Note On message takes about a millisecond (0.960) to send over the wire. If any other MIDI traffic is going on (aftertouch, bends, controller events), transmission of Note Ons can easily be delayed a bit (which increases effective jitter).

I want to emphasize that none of this MIDI jitter is Sonar's fault. This kind of MIDI jitter occurs at the MIDI interface and Windows driver level, not in the sequencer application level.

For the kinds of music most people do, 2 milliseconds peak jitter is probably acceptable (depends on how fussy you are).

The only way to reduce jitter levels further -- would be to change what's going on that those lower levels of the 'MIDI processing stack". This is what the "time stamping" MIDI interfaces claim to do (I say "claim" because I haven't tested them").

Edit: Please note that low jitter characteristics don't necessarily mean latency (delay through the interface) is also good. From a software engineering perspective -- it's usually necessary to increase buffering a bit in order to keep jitter bounded, and increasing buffering will inevitably increase latency as well. I haven't tested the current MOTU interfaces. When I tested a serial-port-interfaced MIDI Timepiece II (around 1999-2000), I found the jitter was excellent (under a millisecond), but that latency was about 10 milliseconds. This is borderline IMHO. But, this measurement of a different MOTU product, 8 years ago -- doesn't imply anything one way or the other about current MOTU products.

For the record, dewdman42 reports excellent (low) latency with his current parallel-port-interfaced MOTU MIDI interface (which does not use timestamping, aka MTS). Sorry for misrepresenting dewdman42's statements in the original version of this post.

- Jim

LionSound --

You asked about Edirol's "FPT" (Fast Processing Technology). It's not MIDI Timestamping. Here's how FPT was described in a SoundOnSound review
(http://www.soundonsound.com/sos/Dec02/articles/edirol700.asp)

"Fast Processing Technology (FPT), a driver and hardware-based solution that allows MIDI data to take best advantage of the potential transmission speeds of USB. While the driver side of the FPT formula optimises the available USB bandwidth depending on the amount of MIDI data coming across the wire, the hardware end of the system attempts to optimise how the data is processed."

FPT is also used in the UM880 and UM550 (I own a UM550 and hope to compare it informally with some other MIDI interfaces later this weekend...once I get a new furnace filter and deal with some other chores ). When Martin Walker tested the UM880, he found peak jitter of about 2 miliseconds. This is quite good for a USB interface of that period - and a lot better than first-generation USB MIDI products. Martin described it as having "slightly better than average timing" in his capsule review.

I find it interesting that the FPT products emerged a year or so after I demonstrated that USB MIDI had serious problems (at the Windows Audio Professionals Roundtable, Winter NAMM 2000, organized by Cakewalk). I'd like to think that my work encouraged Edirol to "go back to the drawing board", but that's never been confirmed.

Jim, notorious MIDI curmudgeon

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.

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.

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.

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

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.