Midi Jitter during playback !!!

What way of working does it interfere with? AS this:

The exported file is rock solid (tight) the realtime output jitters. Imagine what it does when you trigger external gear and make a realtime recording out of that.

is ambiguous. As a realtime recording (ie: to audio) is, to my present understanding of this sentence, the same as exporting.
Stacking is also much more reliably done inside of any synth due to the application of jitter artifacts thru cables, connections and mismatches with other circuitry.
Also layering sounds from drum synths will naturally reproduce timing inconsistencies due to the different sounds recorded and their placement in the sample.

What I think may be happening is that Cubase plays the external synth while other DAWs record it.
This way soundings on the external synth will not match a fixed recording (bounced) due to the synths continuous convolutions.

What standard tools are you using to measure the jitter? Do you get an eye diagram that confirms this?

I believe that what you have here, and is hinted at in the thread title, as during playback means it is to an external synth, is simple latency coupled with the synths convolutions leading to a mismatch between a previously recorded part and an incoming playback of the same part.

Looking at the complex details of jitter I can surmise that if anyone was certain that this was jitter then they’d also know how to fix it.

Don’t see the OP’s complete system and DAW specs.

Also the main reply here may be useful as Pro-tools seems not entirely free of jitter:
http://www.lavryengineering.com/lavry_forum/viewtopic.php?t=7

BTW I layer drums quite often and have never noticed any show-stoppers in this respect. Mind you, I don’t generally blanket-layer a whole performance but emphasise weak parts mostly.

That’s the point!
Take some time to do a very simple test and you’ll notice there is something “shifty” going on between exporting or recording the playback signal.

  • New project

  • Add Groove Agent One (Preset Pop Kit) + midi track

  • Play a bar of rimshots (c#1)

  • Export it 2 times

  • Import the 2 export files and phase reverse 1 of them

  • mute the Groove Agent

  • Hit play
    - Result = NULL

  • Delete the audio files

  • Unmute Groove Agent

  • Record the output of Groove Agent to the 1st audio track

  • Stop

  • Now record the output of Groove Agent the 2nd audio track

  • Phase inverse 1 of the audio tracks

  • Hit play
    - Result = not NULL

I did the same test with Studio One on the same hardware with the same ASIO driver and the export and the recordings of the audio both nulled.
In Studio One even the export can be nulled against the VSTi after you shift the sample -0.06ms
With Cubase that’s impossible because the shifts in playback are totally random.
So it has nothing to do with midi clocks or other HW.

Whether it’s a showstopper or not is not the questions. Different styles, different needs.

did the same test with Studio One on the same hardware with the same ASIO driver and the export and the recordings of the audio both nulled.
In Studio One even the export can be nulled against the VSTi after you shift the sample -0.06ms
With Cubase that’s impossible because the shifts in playback are totally random.
So it has nothing to do with midi clocks or other HW.

The highlighted sentence seems to contradict the previous one.
Also I’m failing to see where in the real world of work the example you give would adversely affect any resulting recordings, or indeed, any prodessing.
I’m also unconvinced that the nature of the GA drum synth engine is not being recorded twice and convolutions and sample placements aren’t changing. What are the results if you try it with Halion drums?

In your second example instead of recording twice from GA, record just once and then simply copy that track to the second audio track. I reckon you’d find a null there. Which would point to a convolution effect from GA.
Look up jitter. Clocks and hardware are what both cause it. Not software.

The highlighted sentence tells us Studio One’s realtime playback of midi data and export are consistent unlike Cubase.

Noticeable phase cancellation may occur randomly in the higher frequency range (due to the relatively small shifts) when layering a VSTi over audio material. Again, when exporting, timing is spot on.

Another situation is when one would like to record the output of the realtime playback to an alternative source. Every recording of the realtime signal is slightly different and never as it is due to inconsistent timing. The solution is pretty simple of course, first make an export before recording to an alternative source.

I don’t have Halion. Did the test with Battery in both hosts and the result is the same

The second test shows the realtime playback of Cubase isn’t consistent. Recording it twice is essential to demonstrate that. Nulling a duplicate of the recording would be pointless to prove anything related to inconsistent realtime playback of midi in Cubase.
No offence, but due to the fact you ask me to do a NULL test with a duplicate of the recorded signal indicates you really don’t have a clue what the purpose of the tests are and what the issue is here.

You don’t have the Halion One that came free with Cubase? You have rather less than a clue here.
I think you’re making it up. I don’t need to waste any more time here. Have a nice moan.

Cats moan :laughing:

That’s exactly my point. I read somewhere that midi driver within win xp causing the jitter, but Im wondering why there is no randomization in other DAWs?
Has anyone test this in other OS? win 7 or Vista?

Oh - I’m not alone.

There’s definately something going on that’s causing drift in midi timing. Random it seems?!

It could be the midi driver or systemclock, but that still doesn’t explain why another sequencer on the same system is able to be rock solid in midi timing (corrects possible jitter) and the other is randomly shifting in time indeed.

I did a simple test in Cubase and Studio One where I recorded the midi output of midi channel 01 to the input of midi channel 02 by connecting a midi cable from my RME’s midi out to the midi in.

The result is as we expected. Studio One’s output is spot on and Cubase’s output randomly drifts from 0.0.0.0 to 0.0.0.2 bars (see attachment).

It doesn’t matter on what tempo you work. The result stays the same. Of course anyone working on lower tempo (from 100 bpm down) will notice these artifacts in real time playback easier then someone working on higher tempo. (edit: I did a test on higher tempo and the higher the tempo the greater the shifts in time)

Maybe a Steinberg dev could chime in to explaine the how’s, what’s and why’s!?



As the devs are not always or slow responding here it may be useful to ask at the Studio One forum to ask how their midi is handled. They may automatically render the midi somehow to audio (autofreeze?) either at recording or it is automatically fed back on rendering to both tracks thereby making it seems as though one is hearing a midi and an audio track but in reality just two audio tracks. Not saying it is just that it might be.

I suggested using Halion One drums to test as if this sounded normal then the problem could indicate that the issue is with GA and not the whole Cubase midi engine.
Saying that, over the years Cubase has, on the PC, had several problems with the midi timing leading to the introduction of mid time stamping and it has always had priority settings which may, or may not, improve the midi / audio match on phase switching. There may still be anomalies there but I don’t think they should be called jitter which is a different beast altogether.

Jitter can be present in any number of the components used but Cubase alone could not be reliably blamed for it’s appearance. However Cubase could be missing some tricks in the correction of any midi jitter introduced by other components.

Ah!?

I did a simple test in Cubase and Studio One where I recorded the midi output of midi channel 01 to the input of midi channel 02 by connecting a midi cable from my RME’s midi out to the midi in

The OPs original test was to render a midi track to audio and then null test but still it seems valid.
Were you using GA1? What happens if you use Halion One’s drums?

I’m going this way because if we are to establish this anomaly any Steinberg devs need to know where the problem lies. As the original post could point it to quite a number of places.
If they can blame something else, like any company, they probably will.

Ok. Tested Halion Sonic SE against itself: Copy of midi drums to another track. Properly nulled.
Copy of midi drums to audio. Properly nulled.

Copy of GA produces noticeable phasing both to a midi copy and to an audio copy and negative null phase.

Therefore the problem is with GA and I’m not sure but I think that may be logged as a problem but it could be down to how GA handles it’s samples and if there are random sample hits to introduce “realism” to the resulting tracks. Now, me being me and knowing my drums and drum machines, somehow that gives me no surprises as no two “performances” would generate the same output.
Would also explain how other DAWs would not return the same results. But it wouldn’t surprise me if someone came up with different results. :mrgreen:
If I get time I’ll test Halion Sonic again for audio to see if it’s not a “one-time” thing as somehow I would expect, seeing GAs results, that there would be some phasing present.
Also, in view of Nile’s report I forgot to look at the Key editor to see if any notes had physically moved on the grid or whether the phasing I heard was sample displacement rather than midi data although to my ears it sounded like just the samples.

Steinberg reps, Chris, JHP, crohde, maybe any of you could shed some light on our findings and what’s causing them.

more like Windows 7 issue.

in OSX, Atari, Linux, and win XP and older windows, midi out is fine with any interface.
but in win7, no matter what interface you use, even if you go directly with usb if you device has it ther will be very noticeable variation in timing coming out from win7 machine to your hardware if you have more than about 3 tracks going out.

I’d expect this. GA is a synth and as such each hit would, and I would expect it to, be slightly different each time it is played back. This is not jitter. It is convolution. Just like a normal synth using string or other samples or synth egnerations.
“Different styles, different needs” ? Are the goalposts being moved now?

Sure, this might interfere with some uses but only very rarely and not the usual uses which a DAW should be put to at present. If more users find more uses and it does need to be more exact I’m not at all sure that it could be done easily at present.
If it holds ops up then it’s fairly easy, as you have illustrated, thanks, to do things another way and get the same result.
No good banging your head on the same nail if a hammer will do the job with less pain. :mrgreen:

Funny, I’ve just been in a thread about humanising the drums where this amount of precision seems not to be the desired object.
The only time I need any layering is with hardware drumkits played live, rarely on recording as there are several ways to get the same effect without stretching the limits of the instruments used.
And I have to say again (and again) don’t call it jitter. Jitter is a hardware issue and will not be addressed by any sofware devs. Something else might but jitter in this sense is another fashionable wrong term for convolution.

Also the jitter is induced by the computer itself as the midi packages for the two generations of GA would trigger it at different times.
You could try setting your Priority towards midi rather than audio which may improve the timing correction.



The clueless kitty is spamming/trolling as usual. Why do you have to display your utter lack of knowledge again and again? OCD, or what?. Convolution, as a mathematical concept, have nothing to do with the OP’s problems. And if you think I’m wrong then please, enlighten me: what is convolution?

And jitter doesn’t have to be a hardware issue. Educate yourself, please!

Kris.

No. You tell me smartass. I will wait for your explanation for a couple of years.
I don’t pointlessly comment like you do to anyone else’s posts. Explain yourself sensibly and professionally or butt out. Idiot.
At least the other posters are willing to be coherent and actually provide reasons for their thinking and allow me mine even if we don’t agree. I’m not a yes man or a + one man or a troll and I don’t have to insult others to explain myself.
I left that kiddies playground a while ago.

This is not true. I can confirm this bug on my XP machine and on my MBP as well.

Some time ago i investigated this problem and could nail it down at least on my machines that, if you compare the midi part against the exported audio in a null test, the midi slips out of time 1 sample back and forth! you can easily check if you switch your time line to “Samples” and then move the exported audio back and forth by using your mouse wheel to change the start point of the audio part in the info line above. I experienced this behavior @44.1kHz. Never checked 48kHz or higher…

Ola Kris, just hit
to mute the unwanted track :wink: