Please give as many details as you can about the setup you used to create this problem and I will see if I can recreate the bad timing here.

1. Open a new project file.

2. Set to 960PPQ and 120BPM.

3. Insert a MIDI track and the TTS-1, and set the output of the MIDI track to the TTS-1.

4. Open the MIDI track's PRV.

5. Create a series of 64th note events with 15-tick duration on Eb6 (this is the Claves sound in GM Drums).

6. I copied them to 128 measures, but you can already see the problem in measure 1, so 8 or 16 should be plenty.

6.5 Oops forgot. Pan hard left, and set output level to max for best results.

7. Select the MIDI track and the TTS-1, and bounce MONO to Track 3.

8. Disabling Fast Bounce made no difference.

8.5 Go get a beer from the fridge.

9. Turn on PRV in the Track View.

10 Zoom till you can see two events and their corresponding wave pulses.

11. Scroll around, and you should immediately see that some transients start closer to the beginning of the MIDI event than others.

12. Zoom further until you can clearly see individual samples.

13. Set the Now indicator to show samples (click it to scroll through the formats).

14. Scroll to the first zero-crossing *after* the beginning of a wave pulse, and write down the sample values (MS Excel can be helpful here).

15. Scroll to the next drum hit, and find the same first zero-crossing, and record the sample value. Repeat several more times, recording the values, and subtracting them to find the interval between hits.

16. If the project is set up as described (and you run 44.1k sample rate like I do), the nominal distance between two drum hits should be 1378 samples. If you get the same result I got, you will find many intervals of 1407 to 1414, with every 4th or 5th one being 1274. If you run a different dample rate, just scale the numbers accordingly.

1274 is 104 samples (4.5ms) short of what it should be, but because all the other intervals are a little too long, things get close to being back on track every 4th or fifth pulse. To me, this looks like a typical case of some sort of cyclic mathematical MODding. Could be a programming error in the rendering algorithm of the TTS-1, or somewhere else in Sonar. I don't know. I haven't yet tried this with another soft synth.

Finally, I should mention that you may be tempted to use AudioSnap to find the transients. I did, and found that AudioSnap has problems of its own. I'll leave you to see these poblems for yourself. Suffice it to say that it is only partially helpful in this effort.

Phew... I need another beer. Hope I got everything right.

Dave

ORIGINAL: brundlefly

If your going to do this I'd suggest you use a sine wav or a square wav around 1Khz.

I've got the sample. A single cycle of a 1000Hz sqaure wave, I used it to do latency testing on audio. But I don't think I have a software smapler in my aresenal, unless something bundled with Sonar6 SE can do it.

Dave

Hi Dave,

Actually I'd make it more than a cycle. Because of slew rate and other factors I doubt it will reach maximum output. You also need enough cycles to readily see it in the wav editor. If your going to use 64th notes then make it a little less then that long. Keep in mind that at 120-BPM, a quarter note is 500ms so working at 120-BPM is a good tempo for configureing your time.

The thing about useing sidestick, hihat, or other percussive sounds is that unless you can go in and see exactly the way they've edited the wav forms then you really don't have a clue where you're at. However, if you don't have a softsampler then you may not have a way of useing your own wav forms.

At any rate, I'm very interested to see what results you come up with.

T.S.

I will try the TTS test later tonight

Actually I'd make it more than a cycle. Because of slew rate and other factors I doubt it will reach maximum output. You also need enough cycles to readily see it in the wav editor. If your going to use 64th notes then make it a little less then that long.

1 cycle of 1kHz works great for me on all counts. I can hear and see them clearly, and they go to exactly the level I set (-3dB in this case - gotta keep the output level turned down!). The clip view of the original wave is a perfect square. When you re-record it through an anlalog input, you get a little bit of "anticipatory" rise in the signal level for about a dozen samples before the leading edge of the square, but then it pops right up to peak level in no more than two samples with the vertical parts of the recorded pulse lining up perfectly with the source. It's a thing of beauty. I can send you a screenshot if you'd like (or maybe post one somewhere, so I can link to it in a post on the forum).

The thing about useing sidestick, hihat, or other percussive sounds is that unless you can go in and see exactly the way they've edited the wav forms then you really don't have a clue where you're at.

I'm not sure what you mean by this. Again, it worked perfectly for my purposes, except for having to painstakingly pick out the first zero-crossing in each pulse. The square wave would have made this a lot easier.

At any rate, I'm very interested to see what results you come up with.

I think I've pretty much described most of the key results. There are a lot of interesting little details I observed along the way (like AudioSnap completely missing transients identical to the dozens of others that it found, or putting the transient marker in the middle of the pulse where there is a tiny modulation of the base frequency) that were a little off-topic, so I've left them out for now.

Let me know if you're looking for something specific that you wanted to hear about. The only other test I'm thinking about doing right now is a re-run the rendered-wave timing test with a different soft synth, but I only have the ones that came bundled with Sonar, 'cause I've always used hardware synths. I'm curious to see what results people get from other DXis/VSTs.

Incidentally, I've done a lot of data analysis and hardware/software product testing and development support in my career. That's where both my interest and creative testing methods come from. My last job was with a company using the rectified-but-unfiltered signal output of cathodic protection rectifiers to analyze coating condition on underground oil and gas pipelines, so this work is very similar to what I did for them.

Keep in mind that at 120-BPM, a quarter note is 500ms so working at 120-BPM is a good tempo for configureing your time.

I thought the same thing initially, but I've just decided the magic number for testing at 44.1kHz is 56.25BPM. This is the highest tempo you can have that will give a whole number of samples per tick at 960PPQ. The resulting values of importance are:

900 ticks/sec (1.111... ms/tick)

49 samples/tick

47040 samples/beat (at 4/4)

30 ticks/frame

I figure this should take all rounding errors and related artifacts out of the system if the timing master is samples. My initial test of TTS-1 rendering at this tempo still found timng errors of 100 samples or more, though at this tempo, that's only about 2 ticks.

Correction: Looks like 78.75BPM is the highest tempo that will give a whole number of samples/tick, 35, which is a nicer number in some ways, but ms/tick gets uglier:

1260 ticks/sec = .79365... ms/tick

35 samples/tick

33600 samples/beat

42ticks/frame

Correction 2: Doh! Brain not working so well today. 131.25 (21 samples/tick) and 183.75BPM (15 samples/tick) will also work, and stay under the 200BPM limit (?) in Sonar.

But I found that the lower tempo 56.25 still works best because AudioSnap finds all the transients in roughly the right place. Apparently the higher tempos have the tails of the pulses running into the next beat, which confuses AudioSnap, even though the transients still look clear.

Details, details, and more details...

its the millesconds you need to care about, not ticks. The number of ticks is irrelevant when rendering through a VSTi. And I think that the timing should be perfect in this case.

ORIGINAL: Jim Wright

As pianodano wrote:
>> I wonder if I am the only one getting the feeling that the existing underlying engineering/ architecture is a piecemeal affair ?

Nope. Frankly, it's totally piecemeal. MIDI was developed starting in 1979 (Dave Smith's 'Universal Synthesizer Interface' AES paper; I was in the audience), and first shipped in 1983. It was designed to be as cheap as possible. It was not designed with any thought of synchronizing with audio, or video, or doing anything but hooking two electronic music products together. Everything after that -- just grew.

Different companies proposed different ways of syncing up MIDI with audio, video, whatever. Some of 'em worked, some didn't. Some of the better ideas -- died, because the people with those ideas were lousy businessmen. Some of the sketchier ideas -- made it in the marketplace, because their inventors were much better businessmen than engineers. Kind of like the rest of the computer hardware/software revolution that happened over the last 30 years....

I've been involved with MIDI and AES standards work since 1981, off and on. There is no grand design. There's just a lot of people trying to work out the best compromises they can, considering both what we (music geeks) know how to build, or code, and what the marketplace seems to want.

Kind of shocking, isn't it ?

- Jim

Great ! We have DAW's designed by commitee.

its the millesconds you need to care about, not ticks. The number of ticks is irrelevant when rendering through a VSTi. And I think that the timing should be perfect in this case.

I think it's really the sample interval that's the key, since there are 44.1 samples/millisecond. Since the MIDI events that are being rendered to audio are "quantized" to 1-tick intervals, you'll get small rounding errors if there isn't an even number of samples per tick. Turns out not to make a real difference in testing, since the rendering errors are on the order of 100 samples, but I wanted things to be as clean as possible.

You are confusing when jitter can take place. You can't get MIDI jitter purely within SONAR while bouncing or freezing. (irrespective of whether its a fast or slow bounce)
MIDI events stored in a SONAR project are timestamped. When you bounce to a softsynth, the MIDI events are fed to the synth with the timestamps implicitly locked to the audio buffers. There is no chance of jitter occuring in this scenario since the synth knows exactly when to render the audio for the MIDI based on the current sample position and the timestamp on the MIDI event. Jitter doesn't apply at all here.

ORIGINAL: dewdman42

Anyway, back to Sonar...... This weekend I am going to try to run some tests where I freeze tracks to audio and compare the midi notes to the waves I see on the audio track to see if there is any jitter happening during freeze or mixdown.

After that i will try to capture the audio that is playing when I am just hitting play and playing midi tracks through soft synths. then I compare that audio track to the midi track to look at the waves and try to determine if there is jitter happening.

Those two situations are what I am most concerned about right now. If Sonar is screwing that up, then Cakewalk needs to get busy....

oh, i see what you're saying. Well in any case, 100 samples off is not ok. The midi ticks can get confusing since it depends so much on tempo and resolution. But even if there is a rounding error and off by one sample or something, its not worth worrying about. Pick any old tempo and any PPQ, the rendered audio should be within a sample or two of exactly where you would expect it to be.

Me personally, I would be satisifed with the audio being anywhere within 1ms of where I expected it to be.