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

The range of accuracy is about 4 ticks. Very surprising..

This is virtually identical what I reported earlier: max error from expected time of about 1.5 ms = 3 ticks at 960PPQ, 120BPM.

In my experience, MIDI sync should put the events right on the same tick.

Ouch, you're right. I was calculating milliseconds wrong. Sorry about that.

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.

Maybe they use a random number generator to humanize the output :-)
Only half joking.

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

One final thought on this before I call it a day:

The only "issue" with the timing of the TruePianos rendering was that all the rendered notes were a consistent 300 samples behind the MIDI event. In thinking about it, this makes sense, as my buffer latency is 300 samples which means that any audio being played back will be 300 samples late, too.

One way to do a quick check of how things are synched up which I have used on occasion is to click the wave inversion button of the rendered wave, and play it back along with the MIDI-driven soft synth (this works well for checking manual latency offsets, too) If the timing is good, the inversion of the rendered wave should cancel out the real-time signal and give you perfect silence (depending on level settings, it may be necessary to adjust the level on one of the tracks to get perfect cancellation).

This works nicely with TruePianos; it's possible to get perfect silence. But with RealGuitars, the variable timing of the rendered notes makes the synch go in an out, so you get little fits and starts of attack sounds, and the cancellation is never perfect.

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?

ORIGINAL: brundlefly

One final thought on this before I call it a day:

The only "issue" with the timing of the TruePianos rendering was that all the rendered notes were a consistent 300 samples behind the MIDI event. In thinking about it, this makes sense, as my buffer latency is 300 samples which means that any audio being played back will be 300 samples late, too.

I disagree, the midi events should not be 300 samples late, regardless of the buffer. All internal calculations and delay compensation should be taking care of all of that and making sure that every midi event renders audio that is located at exactly the same place in time as the midi event.

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.

Delay comp has nothing to do with whether audio from a synth is rendered late. Most synths I know of do not even expose delay. Delay is primarily exposed from fx like compressors that need lookahead before they can produce audio.