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 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.

So basically what you're saying is that rendered audio should be relocated in the time line so that it displays in synch with the MIDI notes. This makes some sense, but then you have an issue with playback timing. If you replay the MIDI track through the soft synth in parallel with the rendered audio, they'll be out of synch, because the soft synth will still be playing back behind the indicated beat, but the audio will be right on it. Since actual audio synch is more important than visual synch, you probably wouldn't want to do that.

The only way around this that I can see would be to store a "display offset" value with each audio clip, kind of like the Time+ parameter for MIDI tracks that lets events play back earlier or later than they are shown in the timeline. This could be done, but the programmer would have to take care to make it work seamlessly with all the possible edits that might later be applied. And things could get ugly if the user changed hardware of soft synths later on, invalidating the stored offsets.

All things considered, I think I'm okay with the status quo, now that I understand it. I will just endeavor to use soft synths that deliver consistant relative timing between events, regardless of what the absolute delay might be.

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.

Noel,

So if I understand you correctly.. Sonar does not apply any delay compensation to softsynths?

Softsynths are not expected to have any delay unless intended by the softsynth on purpose or perhaps shoddy synth programming?

And there is no concept for DXi and VSTi's of delay compensation in general?

If that is the case, then anyone who is experiencing shoddy timing while freezing midi tracks can't do anything about it but blame the plugin, though I have to say, we will never have any way to know for sure it is the plugin's fault. You would have to try using the same plugin in some other DAW's to establish whether its Sonar having a timing problem or the plugin itself. At this point, Noel is very sure that its not Sonar. This leads me to want to know which plugins have timing problems. I would also like to know why Pianodano complains that he makes RealGuitar sound great in Sonar while playing back but then when he does a freeze the timing is off. ??? Why would the plugin do anything different during play vs during freeze?

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 was not under the impression that anyone was using anything with an intentionally long attack. If a soft synth was adding another 10ms of latency between receiving midi and outputting the audio for no reason other than shoddy programming or complex programming...then I would probably never use that soft synth again. Even more so if the synth is doing it haphazardly or randomly.

What I heard in the past few days is that TTS has shoddy programming in it. I have not tried it yet here. It sounds like the implication here is that RealGuitar has shoddy programming too. What else?

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.

I propose we start keeping a list of soft instruments which are known to have timing problems when bouncing to audio.

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

RTGraham -

Sorry, didn't mean to misrepresent you. You're correct, you did not in fact state exactly what I paraphrased - I sort of summarized a couple of different points that you made in a few posts, because they seemed related; but now it looks like I'm putting words in your mouth. My apologies - just trying to draw connections.

Not a problem, and no need to apologize. It's my fault for being so mysterious - I work for a research lab, and unfortunately have to be careful about describing certain kinds of ideas until I get the right kinds of clearance. Which is very frustrating at times , but that's hardly your problem

Best,

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: dewdman42

I would also like to know why Pianodano complains that he makes RealGuitar sound great in Sonar while playing back but then when he does a freeze the timing is off. ??? Why would the plugin do anything different during play vs during freeze?

Me too. Pianodano - are you freezing tracks with Fast Bounce enabled? Have you tried it both ways? If so, did you notice any differences? The Sonar help is pretty clear that some plugins require a realtime bounce (such plugins don't work correctly during Fast Bounce).

- Jim