Noel Borthwick [Cakewalk]
Cakewalk Staff
- Total Posts : 6475
- Joined: 2003/11/03 17:22:50
- Location: Boston, MA, USA
- Status: offline
RE: MIDI "Jitter" - It Does Exist
2007/10/12 16:39:05
(permalink)
Sorry I haven't read the entire thread - what 100 samples off are you referring to?
|
dewdman42
Max Output Level: -74 dBFS
- Total Posts : 839
- Joined: 2004/09/20 16:37:27
- Status: offline
RE: MIDI "Jitter" - It Does Exist
2007/10/12 16:40:02
(permalink)
ORIGINAL: Noel Borthwick [Cakewalk]
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.
Noel, thanks for chiming in. That is what I would have expected also and counted on. So far I have not experienced anything to challenge that, but some other people on this thread seem to have. Still trying to get to the bottom of it.
|
dewdman42
Max Output Level: -74 dBFS
- Total Posts : 839
- Joined: 2004/09/20 16:37:27
- Status: offline
RE: MIDI "Jitter" - It Does Exist
2007/10/12 16:43:13
(permalink)
Noel,
And also, let me ask you, you mention that fast or slow bounce should have no jitter... is the same true for when I hit play on the transport to listen to my midi tracks as they play through the soft synth plugins? Is the same audio timestamp used by plugins during that as when freezing or bouncing?
|
dewdman42
Max Output Level: -74 dBFS
- Total Posts : 839
- Joined: 2004/09/20 16:37:27
- Status: offline
RE: MIDI "Jitter" - It Does Exist
2007/10/12 16:45:41
(permalink)
ORIGINAL: Noel Borthwick [Cakewalk]
Sorry I haven't read the entire thread - what 100 samples off are you referring to?
Its long, complicated, but interesting thread with many tangents that are interesting nonetheless. That is why you thought I was "confused" but its ok I forgive you.  I encourage you to check it out(the whole thread). I think in the end Sonar is going to reign supreme as king of pc midi tightness but we're just proving it out right now. Another question I have is about how Sonar can handle hardware midi timestamping from interfaces such as the MOTU stuff.
|
Noel Borthwick [Cakewalk]
Cakewalk Staff
- Total Posts : 6475
- Joined: 2003/11/03 17:22:50
- Location: Boston, MA, USA
- Status: offline
RE: MIDI "Jitter" - It Does Exist
2007/10/12 16:47:11
(permalink)
It should be identical yes. Exactly the same timestamps are used at bounce time as are used at playback time.
During a (fast) bounce all thats different is that the audio is being pumped fast (not locked to the drivers sample clock) but the relative timestamps for events should be identical.
|
dewdman42
Max Output Level: -74 dBFS
- Total Posts : 839
- Joined: 2004/09/20 16:37:27
- Status: offline
RE: MIDI "Jitter" - It Does Exist
2007/10/12 16:49:44
(permalink)
Excellent. What I would have expected. The people that are reporting otherwise we need to understand why they are experiencing otherwise and try to get to the bottom of what it is they are experiencing.. From my end, my playback seems rock solid also.
The only thing that is kind of not great is the playing of a midi controller in while trying to record a midi track, which seems to have a lot of wishy washy timing in milliseconds due to many factors that are out of Cakewalk's control I realize, but still frustrating. That is how I see it.
|
brundlefly
Max Output Level: 0 dBFS
- Total Posts : 14250
- Joined: 2007/09/14 14:57:59
- Location: Manitou Spgs, Colorado
- Status: offline
RE: MIDI "Jitter" - It Does Exist
2007/10/12 16:59:52
(permalink)
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. Hi Noel, Good to hear form you. I was wondering when someone from Cakewalk might jump in on this. We could use some info directly from the source. What you're saying is kind of what we all thought/expected. But this is not what I'm seeing in my testing. Ignoring for the moment whether a given transient starts right on the beat or not, if what you say is true, the beginnings of transients should be at even intervals (i.e. all early or late by the same amount. But I am seeing differences on the order of 100 samples from the expected interval between consecutive events when rendering through the TTS-1. I just did a test with the Dreamstation DXi, and got smaller errors, on the order of 30 samples. So it seems to be Synth-specific. I have not yet tried a VST instrument. I realize these are tiny errors, and not significant to many of us, but this thread started out being concerned with 1-tick of MIDI jitter, so in that respect, this level of error in rendering MIDI through a soft synth is relevant. Please go back a few posts and find the description of my test method for clarification. Any light you can shed on this will be a welcome addition to the thread. Regards, Dave
|
Noel Borthwick [Cakewalk]
Cakewalk Staff
- Total Posts : 6475
- Joined: 2003/11/03 17:22:50
- Location: Boston, MA, USA
- Status: offline
RE: MIDI "Jitter" - It Does Exist
2007/10/12 17:00:11
(permalink)
OK I'll need several pots of coffee or something stronger<g> SONAR always respects the MIDI timestamps from incoming MIDI unless the IgnoreMidiInTimeStamps flag is set. ORIGINAL: dewdman42
Its long, complicated, but interesting thread with many tangents that are interesting nonetheless. That is why you thought I was "confused" but its ok I forgive you.
I encourage you to check it out(the whole thread). I think in the end Sonar is going to reign supreme as king of pc midi tightness but we're just proving it out right now.
Another question I have is about how Sonar can handle hardware midi timestamping from interfaces such as the MOTU stuff.
|
dewdman42
Max Output Level: -74 dBFS
- Total Posts : 839
- Joined: 2004/09/20 16:37:27
- Status: offline
RE: MIDI "Jitter" - It Does Exist
2007/10/12 17:01:52
(permalink)
ORIGINAL: Noel Borthwick [Cakewalk]
OK I'll need several pots of coffee or something stronger<g>
SONAR always respects the MIDI timestamps from incoming MIDI unless the IgnoreMidiInTimeStamps flag is set.
Right. But one thing I never understood is how the MOTU is able to get a timebase established in order to create timestamps in the hardware. How does it synchronize with Sonar?
|
Noel Borthwick [Cakewalk]
Cakewalk Staff
- Total Posts : 6475
- Joined: 2003/11/03 17:22:50
- Location: Boston, MA, USA
- Status: offline
RE: MIDI "Jitter" - It Does Exist
2007/10/12 17:03:14
(permalink)
It could very well be a bug in the synth. I'll try and investigate your post when I get some time. You should definitely try a VSTi as well since the mechanics are different.
|
brundlefly
Max Output Level: 0 dBFS
- Total Posts : 14250
- Joined: 2007/09/14 14:57:59
- Location: Manitou Spgs, Colorado
- Status: offline
RE: MIDI "Jitter" - It Does Exist
2007/10/12 17:08:21
(permalink)
You should definitely try a VSTi as well since the mechanics are different. I'll see what I can do. Thanks for looking at this in any case.
|
dewdman42
Max Output Level: -74 dBFS
- Total Posts : 839
- Joined: 2004/09/20 16:37:27
- Status: offline
RE: MIDI "Jitter" - It Does Exist
2007/10/12 17:10:18
(permalink)
ORIGINAL: brundlefly
the beginnings of transients should be at even intervals (i.e. all early or late by the same amount. But I am seeing differences on the order of 100 samples from the expected interval between consecutive events when rendering through the TTS-1.
Ok, I want to understand your test better. I didn't get a chance to try to replicate it last night. Maybe over the weekend. But when I tried my simple test, I just looked to see if the midi events in the PRV were exactly lined up with the audio events, down to sub-ms precision. And they were. However, I did not actually attempt to check the number of samples between audio transients to see if the track view was lying to me. That sounds kind of like what you are saying...that regardless of what you see in the trackview, the transients that were frozen into the track were not evenly spaced as you should have expected. You're absolutely sure you're going from the exact start of each transient? 100 samples is more than 2ms, so not insignificant. I will have to take a look at that this weekend, but i would also like to hear what Cakewalk has to say.
|
dewdman42
Max Output Level: -74 dBFS
- Total Posts : 839
- Joined: 2004/09/20 16:37:27
- Status: offline
RE: MIDI "Jitter" - It Does Exist
2007/10/12 17:13:07
(permalink)
ORIGINAL: Noel Borthwick [Cakewalk]
It could very well be a bug in the synth. I'll try and investigate your post when I get some time. You should definitely try a VSTi as well since the mechanics are different.
So the fact that this is a possibility, leads me to believe that we are somewhat at the mercy of our plugins to know for sure they will not screw up the playback timing. Can you please elaborate more on the details involved? I would have thought that all plugins are supposed to report a fixed latency, which Sonar can then compensate for. Are you saying that some plugins may be reporting more or less latency then they are actually producing, which is then causing timing discrepancies when sonar applies delay compensation?
|
RTGraham
Max Output Level: -57 dBFS
- Total Posts : 1824
- Joined: 2004/03/29 20:17:13
- Location: New York
- Status: offline
RE: MIDI "Jitter" - It Does Exist
2007/10/12 17:18:47
(permalink)
ORIGINAL: brundlefly
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.
Very, very interesting. Did you happen to make a timing list of the sample intervals, and compare from beat to beat, and from measure to measure, to see if there was a consistent pattern? I became aware, from the test I did a couple of years ago, of hardware sequencers and drum machines that, while they had no MIDI "jitter," did not have truly equal sixteenth notes. There was a definite pre-programmed "feel" to the sixteenth-note quantization, and a pattern of larger and smaller sample intervals between consecutive sixteenth notes, and what you're describing sounds very similar. I wonder how many drum machine manufacturers do this, without advertising it - and then certain music producing communities (i.e. hip-hop) swear on their mother's macaroni and cheese that a specific drum machine / sampler / sequencer (i.e. MPC3000) just *feels* better than anything else. Of course it does - it's been *groove* quantizing, not absolute quantizing. (I should note that the MPC3000 was *not* in fact one of the units I tested - I only mention it here because it's just a good illustration of a hypothetical scenario.) Back to the matter at hand - when I had run these tests before, I did not find SONAR doing the same "covert groove-quantizing," but given the relationship with Roland (including the origin of the TTS-1), I wonder if there's any possibility that what you're seeing is the same thing. Or, as Noel suggests, it could just be a bug in the softsynth.
~~~~~~~~~~ Russell T. Graham Keys, Vocals, Songwriting, Production russell DOT graham AT rtgproductions DOT com www DOT myspace DOT com SLASH russelltgraham
|
RTGraham
Max Output Level: -57 dBFS
- Total Posts : 1824
- Joined: 2004/03/29 20:17:13
- Location: New York
- Status: offline
RE: MIDI "Jitter" - It Does Exist
2007/10/12 17:32:56
(permalink)
ORIGINAL: dewdman42
My feeling is that playback through VSTi's should absolutely be intertwined with audio sync and should be 100% jitter free. If it is not, as some people seem to be claiming, then Cakewalk has a lot of work to do and I'm not impressed. I haven't noticed any problems here, but some people appear to have.
...
There is no excuse for this when playing through soft instruments since everything is being rendered by the Sonar audio engine, which is supposed to know all about audio buffers, delay compensation, etc.. There is absolutely no reason for the midi timing in that case to not be 100% perfectly tight.
Agreed. I'm glad to see that Noel chimed in on this thread - perhaps, as he suggests, there's some kind of softsynth bug coming into play. When I freeze softsynths from quantized MIDI tracks, I don't see any problem with timing. The only exception I've seen is with softsynths that have known issues with Fast Bounce - if I Fast Bounce BFD or Akoustik, I end up with all kinds of strange audio artifacts, notes in the wrong measures, etc. If I disable Fast Bounce the problems go away. Fairly frustrating, especially when freezing 15 tracks of drums on a 5-minute song, but that's not the issue at hand here. ORIGINAL: dewdman42
The problem that comes up related to midi drivers and recording from a midi keyboard is probably not solvable and we have spent a great deal of time discussing it in this thread and sharing some interesting facts, but its a limitation of windows. At any rate, my perception is that its not actually that bad and that most of the complaints people have are timing differences much much greater than 1-2ms, but rather large and blatantly obvious timing glitches at playback time.
Yes, most of the complaints seem to pop up when there are large and blatantly obvious timing glitches. But as we're seeing in this thread, as people become more informed about the issue, they recall situations in their own experience (i.e. "Guess what - my timing is actually OK when I just record audio instead of MIDI") where the MIDI "jitter" issue has affected them. I think that now that audio stability has reached a certain threshold, it might be reasonable to expect that enough people will be interested in their MIDI being stable as well for it to become both a solvable issue and something that manufacturers are interested in accomplishing. ORIGINAL: dewdman42
But short of just bringing this up all the time, I'm not sure Cakewalk will take action, it doesn't seem to be something that people complain about very often.
I don't know that it's something that Cakewalk can take action on by themselves; it's deeper than just the sequencer. It seems like something that has to happen at a manufacturer level (Jim Wright has suggested that a MIDI interface could be built that references its own, more stable clock, and could also clock to an external stable clock, like word clock, and achieve much greater internal MIDI stability while still being able to reference Windows' current driver APIs), and which, once accomplished, would benefit not only SONAR users but *all* Windows DAW users. I don't know if this carries across to the Mac platform software; I've never done similar testing on the Mac side, so I don't know how much MIDI "jitter" affects Mac MIDI communications. This also is the first thread I have seen on this issue on this forum in a *long* time - perhaps ever - that has gotten this involved, with this much interest and attention, and especially with this many good ideas and potential solutions being discussed.
~~~~~~~~~~ Russell T. Graham Keys, Vocals, Songwriting, Production russell DOT graham AT rtgproductions DOT com www DOT myspace DOT com SLASH russelltgraham
|
dewdman42
Max Output Level: -74 dBFS
- Total Posts : 839
- Joined: 2004/09/20 16:37:27
- Status: offline
RE: MIDI "Jitter" - It Does Exist
2007/10/12 17:35:06
(permalink)
I would not expect sonar to be doing irregular quantizing on purpose. Quantizing is quantizing, unless it is specifically groove quantizing or humanizing, which is a different thing entirely. I think for this test we can assume the midi data is quantized and we would expect the intervals to be exactly the same.
The same test should be run through a variety of DXi and VSTi plugins to see what kind of results we get.
|
RTGraham
Max Output Level: -57 dBFS
- Total Posts : 1824
- Joined: 2004/03/29 20:17:13
- Location: New York
- Status: offline
RE: MIDI "Jitter" - It Does Exist
2007/10/12 17:36:12
(permalink)
ORIGINAL: pianodano
ORIGINAL: Jim Wright
<snip>
I have some ideas about how to build a MIDI interface that uses robust timestamps synchronized with an audio sample clock, but some custom chip design would likely be required. If someone with chip-design chops would like to collaborate on an open-source hardware/software project to do just that -- let me know.
- Jim
I hardly believe what I have read here: that midi is not synchronized to the audio via the sample clock. How did that idea become the standard? What is the SOURCE of the MTC that is generated and output ??
Danny
Keep in mind that when MIDI was first implemented, manufacturers were not thinking specifically about synchronizing it with audio. The first MIDI sequencers, and then the first computer MIDI sequencers, were implemented just to play back synths and drum machines. Audio was added much later, after "satisfactory" methods of MIDI clocking had already become the norm. It happens that audio required significantly more stable clocking solutions - it's much more audibly obvious when there's an audio clock problem - and so by comparison now, we can see how far behind the curve MIDI clocking is in terms of accuracy and stability.
|
RTGraham
Max Output Level: -57 dBFS
- Total Posts : 1824
- Joined: 2004/03/29 20:17:13
- Location: New York
- Status: offline
RE: MIDI "Jitter" - It Does Exist
2007/10/12 17:39:53
(permalink)
ORIGINAL: Jim Wright
BTW - I have some ideas about how to build a MIDI interface that uses robust timestamps synchronized with an audio sample clock, but some custom chip design would likely be required. If someone with chip-design chops would like to collaborate on an open-source hardware/software project to do just that -- let me know.
- Jim
Wow. I don't have those kind of design chops, nor do I know anyone personally who does; but as I communicate with people in the industry, I'll certainly keep my ears open and mention it if it seems like the issue is "discuss-able." It would be great to see a new standard of MIDI interfacing; since we've seen that audio can achieve that kind of stability, it should be possible with the MIDI data stream as well.
|
brundlefly
Max Output Level: 0 dBFS
- Total Posts : 14250
- Joined: 2007/09/14 14:57:59
- Location: Manitou Spgs, Colorado
- Status: offline
RE: MIDI "Jitter" - It Does Exist
2007/10/12 17:50:13
(permalink)
You should definitely try a VSTi as well since the mechanics are different. Indeed it seems they are. The only VSTi I have is TruePianos. I thought it might give me trouble finding transients given the long decays of piano notes, but it turned out not to be a problem; AudioSnap found them all, and marked them lal in exactly the same place. That place was a little way into the visual start of the transient at 300 samples behind the MIDI event, but... Drum roll please... Every interval was identical, and equal to the expected value (2940 samples for 64th notes at 56.25BPM)! 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.
|
RTGraham
Max Output Level: -57 dBFS
- Total Posts : 1824
- Joined: 2004/03/29 20:17:13
- Location: New York
- Status: offline
RE: MIDI "Jitter" - It Does Exist
2007/10/12 18:11:46
(permalink)
ORIGINAL: brundlefly
Every interval was identical, and equal to the expected value (2940 samples for 64th notes at 56.25BPM)!
Cool beans... so we're seeing that at least under certain circumstances, rendered softsynth MIDI data is stable as expected.
|
Jim Wright
Max Output Level: -66 dBFS
- Total Posts : 1218
- Joined: 2004/01/15 15:30:34
- Status: offline
RE: MIDI "Jitter" - It Does Exist
2007/10/12 18:17:32
(permalink)
Noel - good to see your input! I would also expect that softsynths should get exactly the same timestamps from Sonar at all times, during both regular playback, bounce, fast bounce etc. Any apparent softsynth jitter - seems likely to be caused by the particular softsynth, not by Sonar. (I'm assuming this because the direct Sonar-to-softsynth connection completely bypasses the particular Windows and MIDI-driver problems that I've seen cause jitter for MIDI traffic to/from the actual MIDI DIN ports.) I will try to test some softsynths this weekend to see if I see any of the jitter issues that others have reported (I'll probably try Atmosphere - which has test tone programs - and Kontakt 2, rather than TTS-1; I may also try DimPro). I'd also like to do some tests with a padKontrol, external synth module and Sonar, to compare MIDI performance when the same source (padKontrol) is used to drive both an external module (Korg NS5R) and a softsynth (Battery 3, DimPro, Atmosphere....). How would I test? Here are some ideas. - I'd route padKontrol to both NS5R and several MIDI ports (Edirol USB, EMU PCI, padKontrol USB...) and record all the MIDI inputs as separate tracks, simultaneously. Then, I'd look for jitter and skew in the various tracks. That would let me compare performance of padKontrol USB MIDI (up the USB cable to Sonar) with EMU 1820M MIDI IN (patching padKontrol MIDI DIN out to EMU MIDI DIN IN), and with Edirol USB MIDI (patching padKontrol MIDI DIN out to UM-550 MIDI DIN in, which appears as a different USB MIDI IN port to Sonar). By the way -- obviously, playing the padKontrol pads directly is not going to produce notes that fall exactly on any particular beat, or audio sample count, or millisecond. I don't care about the absolute timestamp of any particular MIDI event. What I'll be looking for is how much latency and jitter is introduced by different MIDI ports and drivers, that are all processing the same original source note (a single hit on a padKontrol pad) and are all being recorded in parallel. - In Sonar, I'd route the live MIDI input (either padKontrol USB MIDI, Edirol USB MIDI or EMU PCI MIDI) to a softsynth (Battery 3, Atmosphere, Dim Pro...). I'd then record the audio output from the softsynth to a separate audio track. As a baseline, I'd also record the NS5R output to another audio track (I'm assuming the NS5R has low jitter - which might not be the case. I have some other hardware modules to try if need be). Then, I can (hopefully) compare the relative jitter of different softsynths as they are driven by live, incoming MIDI (handled by Sonar, but not yet recorded/played back by Sonar). I'd also record the live MIDI input for the next set of tests. - Finally, I'd take the recorded MIDI data (captured during the previous set of tests) and use that to drive the same softsynths (and probably the NS5R too). This would result in another set of audio tracks. I could then compare all the different audio tracks (and MIDI tracks created using various MIDI input ports) -- and see what the data shows. If anyone has other suggestions for evaluating real-world MIDI jitter, using something like a padKontrol as the MIDI note generator -- speak up! Original: RTGraham
...Jim Wright has suggested that a MIDI interface could be built that references its own, more stable clock, and could also clock to an external stable clock, like word clock, and achieve much greater internal MIDI stability while still being able to reference Windows' current driver APIs. That's not exactly what I said, but then I haven't given any details of the hypothetical interface. What I have in mind ... is hardware that basically synchronizes MIDI traffic directly with an audio stream, using a MIDI timebase that's inherently aligned with the audio sample rate. The guts of the hardware could probably be done using an FPGA (field-programmable gate array). Sorry to be so mysterious. I would like to take things further, but would need to get permission from my employer to open-source the idea (or find another way of developing it that complies with IP concerns). - Jim
|
RTGraham
Max Output Level: -57 dBFS
- Total Posts : 1824
- Joined: 2004/03/29 20:17:13
- Location: New York
- Status: offline
RE: MIDI "Jitter" - It Does Exist
2007/10/12 18:28:07
(permalink)
ORIGINAL: Jim Wright
Original: RTGraham
...Jim Wright has suggested that a MIDI interface could be built that references its own, more stable clock, and could also clock to an external stable clock, like word clock, and achieve much greater internal MIDI stability while still being able to reference Windows' current driver APIs.
That's not exactly what I said, but then I haven't given any details of the hypothetical interface. What I have in mind ... is hardware that basically synchronizes MIDI traffic directly with an audio stream, using a MIDI timebase that's inherently aligned with the audio sample rate. The guts of the hardware could probably be done using an FPGA (field-programmable gate array). Sorry to be so mysterious. I would like to take things further, but would need to get permission from my employer to open-source the idea (or find another way of developing it that complies with IP concerns).
- Jim
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.
|
dstrenz
Max Output Level: -69 dBFS
- Total Posts : 1067
- Joined: 2005/12/10 09:59:06
- Location: Rochester, NY
- Status: offline
RE: MIDI "Jitter" - It Does Exist
2007/10/12 18:30:14
(permalink)
ORIGINAL: brundlefly
...But I am seeing differences on the order of 100 samples from the expected interval between consecutive events when rendering through the TTS-1. I just did a test with the Dreamstation DXi, and got smaller errors, on the order of 30 samples. So it seems to be Synth-specific. I have not yet tried a VST instrument.
I haven't used it in a long time but the TTS-1 is not the ideal softsynth to use to test Sonar's midi timing. The reason I stopped using it? Download a midi file that contains several tracks and import into Sonar. Set all of the tracks to play through the TTS-1. Add an instance of a different soft synth and route one of the midi tracks through it. The timing is off by a mile.
|
dstrenz
Max Output Level: -69 dBFS
- Total Posts : 1067
- Joined: 2005/12/10 09:59:06
- Location: Rochester, NY
- Status: offline
RE: MIDI "Jitter" - It Does Exist
2007/10/12 18:51:16
(permalink)
Jim, I ?may? have found a fault with the old test and would appreciate your opinion on this if you have any. The first thing done is record audio and midi simultaneously while the sequencer is sync'd to Sonar. But normally, I only record midi by itself without syncing anything. In an attempt to remove audio and synchronization from the equation, I did the following. The results are very surprising to me. Also, I followed your advice and used the emu 1820m's midi rather than the Fantom's USB midi. 1. Record 4 bars of quarter notes on the Fantom sequencer at 120bpm. 2. Save the file as an smf and import into Sonar. (Lets call this clip from the Fantom Fclip) 3. Set up Sonar to record midi from the Fantom (960ppq) hit record, and play on the fantom. Lets call the clip recorded in Sonar Sclip1) 4. With snap-to-grid on, slide SClip1 to line up with FClip to align the first notes. 5. Select both midi clips and View|Event list. Trk 4 = Sclip1, Trk5 = Fclip.  The range of accuracy is about 4 ticks. Very surprising.. Now, to add audio to the equation, I repeated the process but recorded an audio track along with the midi track. Call the new midi track Sclip2. Trk5=FClip, Trk2=Sclip2: Very similar results!? Next I tried to add in midi sync but could not get it to work through the midi cables using the same procedure I used to make it work through USB.
|
brundlefly
Max Output Level: 0 dBFS
- Total Posts : 14250
- Joined: 2007/09/14 14:57:59
- Location: Manitou Spgs, Colorado
- Status: offline
RE: MIDI "Jitter" - It Does Exist
2007/10/12 20:31:30
(permalink)
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.
post edited by brundlefly - 2007/10/12 20:42:33
|
brundlefly
Max Output Level: 0 dBFS
- Total Posts : 14250
- Joined: 2007/09/14 14:57:59
- Location: Manitou Spgs, Colorado
- Status: offline
RE: MIDI "Jitter" - It Does Exist
2007/10/12 20:42:09
(permalink)
Download a midi file that contains several tracks and import into Sonar. Set all of the tracks to play through the TTS-1. Add an instance of a different soft synth and route one of the midi tracks through it. The timing is off by a mile. 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.
|
Noel Borthwick [Cakewalk]
Cakewalk Staff
- Total Posts : 6475
- Joined: 2003/11/03 17:22:50
- Location: Boston, MA, USA
- Status: offline
RE: MIDI "Jitter" - It Does Exist
2007/10/12 21:52:44
(permalink)
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.
|
brundlefly
Max Output Level: 0 dBFS
- Total Posts : 14250
- Joined: 2007/09/14 14:57:59
- Location: Manitou Spgs, Colorado
- Status: offline
RE: MIDI "Jitter" - It Does Exist
2007/10/12 21:59:34
(permalink)
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...?
|
pianodano
Max Output Level: -67 dBFS
- Total Posts : 1160
- Joined: 2004/01/11 18:54:38
- Location: Va Beach Virginia
- Status: offline
RE: MIDI "Jitter" - It Does Exist
2007/10/12 22:04:29
(permalink)
I have never used any of the supplied softsynths so I cannot comment on those. But as I stated earlier, I do use Realguitar constantly. I have tried numerous times to freeze a well tweaked Realguitar track and always found it necessary to unfreeze it. Something changes in the timing when frozen. Now I just put it on the tape recorder. Problem solved. YMMV.  Brundlefly, they may still have a demo of Realguitar over at the musiclab site. I'll go see and let you know.
post edited by pianodano - 2007/10/12 22:35:47
Best, Danny Core I7, win XP pro, 3 gig ram, 3 drives- Lynx Aurora firewire- Roll around 27 inch monitor, 42 inch console monitor- Motif xs controller - Networked P4's and FX Teleport for samples- Muse Receptor VIA Uniwire for samples and plugs- UAD QUAD Neve - UAD 1- Sonar X1 but favor 8.5 GUI - Toft ATB 32 - Vintage hardware - Tascam MS-16 synched via Timeline Microlynx -Toft ATB32 console
|
brundlefly
Max Output Level: 0 dBFS
- Total Posts : 14250
- Joined: 2007/09/14 14:57:59
- Location: Manitou Spgs, Colorado
- Status: offline
RE: MIDI "Jitter" - It Does Exist
2007/10/12 22:06:49
(permalink)
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. This is why I mentioned earlier that I was ignoring the delay for the time being, and just looking at the interval between transients. This interval should be consistent regardless of how much delay there is. This is what some are referring to as "jitter" in rendering.
|