Ola Kris, just hit 
to mute the unwanted track 
Also depends on the soundcard being used (which can have jitter inherent as itās hardware). I see now, besides the goalposts being moved slightly, that the game has changed from this being a Cubase problem to a Windows problem.
What you could try besides different sample rates is to increase the soundcard buffers and do the null tests again to see if it tightens up any. Differences in the midi timing depend on what arrives in each buffer cycle and (depending on clocking quality) when. The more you get in each cycle the more chance they have of closer timing. The latency will be horrendous so remember to change it back to your normal inputting buffer rate.
Since the excellent Atari and, I think, the early Apple machines (which both used the same Motorola chips) there has always been great difficulty apparently getting any version of Windows midi timing right.
Is this ājitterā noticeable without nulling? ie: On normal playback.
How can you tell? As I wrote I can confirm on OS X as well.
What Iāve checked by now:
Win XP, RME9632 (see specs), C6 (32bit), different buffer settings: fail
Win 7 (64Bit), C6 (32bit), RME9632, different buffer settings: fail
OS X (my Macbook Pro), C6 (32bit), TC Konnekt 24D, different buffer settings: fail
OS X (my Macbook Pro), C6 (32bit), buit in audio device: fail
So I would not say itās a Windows thing. Tomorrow I will check several iMacs and see what happens there. As far as I can remember this behavior didnāt occur on SX3, it began with C4.
For my needs I only notice when it comes to layering drums as the highs and mids sound different every hit. See:
Hm, so it also seems an OSX problem. I presume that must be with the newer Macs. As far as friends using Macs were concerned problems with Windows were apparently not present on Macs. But it could have been one of those āMac v.PCā comments and not exactly true.
But it still seems to be a Windows problem as well as an OSX problem so my comment stands.
I would layer the drums as Audio or put two samples per pad if possible or layer using the same (snare) variations on two or more different pads.
But I would still not expect complete synchronisation there (in GA unconverted to audio) either but you may be lucky.
When layering the object usually is to get an interesting texture from the kit which may well involve a little thickening, chorusing or distortion here or there for character.
On bare drums this may at times sound odd but, like real drums, when the other instruments are laid on top those little sound details (some would say imperfections and youād be surprised how many howls, zings and fluffs happen on a real kit) are masked and the imperfections actually add something.
Also recording you can get bogged down with details that donāt really matter. I still sometimes do myself. Itās like the recording product, the music, is in a giant fishbowl and every mistake or nuance can seem as big as the planet. I think this can be one of those cases.
Cubase is not a scientific test-bed. It is, after all, just another way of recording music. Music isnāt a science. Itās an art.
PS: Try recording two REAL drummers doing the same part and tell me what sort of comb-filtering they produce. 
Ok, the implication that cubaseās midi timing, good or bad, has anything to do with the hardware used doesnāt hold a lot of water with me. Are you really suggesting that the crystal clock of the converters (interface) is so unstable that cubase using it as a reference for its midi timing canāt keep up? Do you know how bad that clock would have to be. Midi has, what, 1/50th of the timing of a 44.1 clock?
Midi timing inside an application (not addressing external apps or midi sound sources) is a code thing-either cubase or the VI being used. Nuendo2 had some of the most truly hideous midi timing Iāve ever experienced. That said, cubase 4 and now 6 have been relatively stable for me.
Iāve not run the test hereā¦and frankly, could point to GA1, whichā¦well, I just donāt care. Not sure who uses thatā¦however, I ran a test recently to prove a different point to a friend.
Played a track live (clav so it would have some nice transients)-I simultaneously recorded the audio and midi. Then I rerecorded the audio of the midi track. Then I did a third bounce offline. The a forth and fifth in real time but with several reverence and t-racks issues (latency compensation inducing plugs) on OTHER tracks in the project.
Points proved:
C6ās ADC worked 100%
And my point I was actually making-NOTHING replicated the live audio.
Questionable thing:
While all Three real time bounces nulled, and the two offline nulled to each other, they did NOT null between real time and offline. This could very well be due to Scarbeeās K4 scripting being ātiming sensitiveā and offline does mess with time. Like if it were ādonāt play the same variation within 100ms of each otherā, bouncing offline could throw that kind of scripting off. Iāve also found that bfd2 doesnāt bounce properly offline all the time, so I just DONāTā¦real time saves time in the long run because itās always what you hear.
Anywayā¦the thing I was trying to prove, and did? You can LOOK at the audio versus the midi rendered to audio and seeāsome hits in the midi are early, some late. I was making the point that you should be recording audio rather than midi for anything you can play with your ten fingers. Midi, in this day and age should be for programming things you canāt playā¦drums, horns, strings-things more about programming than playing. The side effect I learned was that cubase 6 on win7x64 is as good as you can ask from a midi sequencer in being consistent in playback timing.
Fwiw, c2quad, 8gb, nvidia mobo chipset, motu 5x5, echogina3g. Kontakt 4ādonāt rembrandt the last update I did, maybe with Aliciaās Keys 1.2? I remember 4.1 because it enabled the background loadingā¦I tend to not update unless thereās an issue or worthwhile featureā¦still on c6.0.
Anywayā¦try your test with a third party sampler. See if you still have the issue. If not, itās likely ga1ā¦what are you using in studio one and protools? Iām really picky about midi timing. C4&6, Iāve had no real issues, save offline bouncingā¦which I resolve by getting a cup of coffee while it bounces in real time!
conman - with almost every post on here you seem to reveal yourself as having no understanding of what it is youāre pretending to be an expert in.
in this thread youāve gone from:
thereās no problem with cubase
to
itās a hardware problem
to
itās a system specific windows problem
to
confusing midi jitter with jitter in digital audio clocking
to
itās convolution
back to
itās not a problem (for you?)
to
the problem is with GA
back to
itās hardware
to
the problem is in with non-motorola chips
to
itās a windows AND osx problem
to
itās a desirable feature
Iāve noticed your random uninformed posts spread thickly around this forum. I know youāre āprobablyā only trying to help but you really need to STFU. Itās like trying to read a book with somebody scribbling sh*t over the page whilst youāre reading. . . . worse still, somebody might read your posts and actually think your random utterances are fact.
sorry I have to be so personal but I suspect that subtlety isnāt in your dictionary.
Help! Who let the chimps out?
The chimps keep commenting on nothing but othersā posts. You have nothing to say about the subject. These trolls that follow people about with inane uninformed comments are starting to clutter the forum.
It seems Iām not allowed to discuss problems and try to resolve them in anything like a professional way but to browbeat Steinberg. Sorry, I donāt play those schoolkid games.
If you havenāt got any idea about the subject then butt out back to the bedroom, kid.
Iām talking about BASICS here. If you donāt understand or can explain why Iām so wrong in a clear and professional way then youāve got to be trolling.
Jitter isnāt a Cubase problem.
Jitter is a hardware problem.
Midi has always been hard to implement on Windows.
Midi takes time (latency) to travel around a computer circuit and travels in things called āpacketsā.All these things I write about and they are all documented and searchable.
I am by no means the expert you say I think I am and you think you are. I never said I was an expert. I just bring stuff to the table to consider and discuss. Which I do without denigrating others.
What Iām saying here is that the OP and the title is wrong. BUT. He does have a problem. What we have to establish is that the problem is with GA and whether it can be fixed by Steinberg or whether the OP needs to change work practise in some way.
My take is that (even sampling) synths like GA generate sounds unevenly and so nulling would rarely take place.
My second take is that a better way to get nulling would be to record two tracks of audio.
And. Double tracking, stacking and / or double sampling is sometimes not easy.
My background: Cubase 20 years, drums, 31 years, engineering 15 years.
Consider yourself told off by a guy who never stops learning but is used listening to fascists who stopped learning long ago. Dr. Chimp.
PS: Apologies to all and thank you popmann for your good post.
Convolution (like multiplication and addition) produces the same result every time. A (straight) convolution reverb ought therefore to produce the same reverb every time - though I believe there are convolution reverbs that employ extra procedures to deliberately introduce some variation/randomisation(?). In (digital) audio, convolution isnāt confined to reverb, but unless thereās another process introducing variation, the results of repeated applications of convolution (in any guise) must always be the same.
IMHO, itās thus confusing/misleading to say variation is caused by convolution if whatās meant is that another process is acting in conjunction with the convolution to cause the variation (deliberate or otherwise).
Convolution, per se, canāt cause two MIDI playbacks to be different.
I Donāt know who this question is directed to, but Iām suggesting nothing. I only share my findings. Like I said earlier, for most users this isnāt a showstopper. But I just find it remarkable one sequencer is spot on and the other not, on exact the same system.
FWIW I did the same test with Battery, Kontakt and Sampletank (all with a single layer sample) and the result is the same.
Random shifts in time when playback is recorded in real time. I did use GA1 simply because anyone using Cubase could reproduce the test. To exclude any specific VSTi or Asio problems I directly recorded the midi out to midi in too in different sequencers, again on exact the same system, the result is in this post.
Please note, these test are not done by bouncing in real time but recording the playback directly from a group.
E.g. record the audio in two independent takes from the same VSTi with a single layer sample and all effects and variables in volume and filters turned off. When you null them against eachother, they are slightly different every recorded instance. While different exports null out.
Remarkable is that when I do the exact same test in another sequencer (Studio One) on exact the same system with the same VSTi (Battery), the independent recording from the playback nulls out. So on my system Cubase isnāt consistent in realtime playback and another sequencer is. My question is, what could that be?
I would love to know if your system acts different when you record the playback in real time. Because when thatās the case, it could have something to do with our setup and maybe narrows it down.
Convoluted = highly complex or intricate and occasionally devious.
You are right mathematically but we arenāt talking maths weāre talking synth (and reverb) terms for sound reproduction. Convolution in these terms serves to make the sound interesting ie: varied. And when a sound varies to find two instances the same would be rare.
To my ears GA sounds decent enough for me, a drummer to ue. This means that the sounds arenāt boring me to death yet, which means there is some āinterestā in there. Some variation must be happening or Iād spot it and not use it.
On nulling. Logic 8 (Apple) seems/ed to have it. Some suggestions are to change the pan law.
Yes, I do know what āconvolutedā means in ordinary English.
So, you were using the word āconvolutionā to mean the condition of being twisted, coiled or intricate, etc, rather than the technical use of the word in maths or digital audio.
Iām surprised to learn that you associate that (complexity-type) meaning with āconvolutionā when speaking about reverb, instead of meaning the type of reverb that works by convolution (in the digital-audio/mathematical sense). IMHO, that usage is VERY likely to cause confusion amongst readers of this forum - I expect that if you use the word āconvolutionā when describing reverb, most of us will think youāre talking about convolution reverb.
If I spoke about the frequency of the A above middle C, forum members wouldnāt expect me to mean how often that note is played. If I said Iād just bought a compressor, they wouldnāt envisage a pump that pressurises gas.
Similarly with other words, such as: note, key, scale, interval, staff, quaver, bar, rest, pause, bow, string, wind, roll, amplify, distortion, fidelity, gate, delay, insert, effects, instrumental, conductor, ā¦ The context (this forum) sets up an expectation that such words have a meaning thatās not the meaning found in ordinary English.
I may be wrong, but I expect the majority of people reading posts in this forum will expect the word āconvolutionā to be used in the technical sense when discussing aspects of digital audio. If Iām right, there, using it to mean twisted/coiled/intricate/etc in such circumstances is, IMHO, pretty well asking to be misunderstood.
Anyway, Iām glad youāve now explained what you meant by āconvolutionā, because I thought for a while that you werenāt willing to say what you meant by it ā¦
Please note, these test are not done by bouncing in real time but recording the playback directly from a group.
E.g. record the audio in two independent takes from the same VSTi with a single layer sample and all effects and variables in volume and filters turned off. When you null them against eachother, they are slightly different every recorded instance. While different exports null out.
I will certainly check that out next time Iām down there in āgeeky modeā. I do get the difference. I never really considered a real time export and a ālive bounceā as having different resultsā¦interesting.
What I was saying about the thing being hardware related was that your audio NOR midi hardware has anything to do with any INTERNAL software timing, except by providing the master audio crystal clock, to which the audio and midi engines sync. Nor does it matter that midi has been troublesome on windows. Because even though the app is running on windows, only EXTERNAL midi would utilize and of the USB or direct sound midi functions of the OS. So, I think we are in agreement that your issue would be host relatedā¦or VI related-and since you clarified you get the same results with other VIs by different developers, I would say it sounds like a cubase bug.
Interesting that the real time exports null, though. Itās as if something is distracting the CPU during the live bounce, where the real time export has a chance to put the hit in the right place after detecting it was interrupted. Do you get these results with a project with only the midi track in question? Alsoā¦have you seen any difference between using an instrument track versus the instrument rack+midi track?
Side note, Iāve often wondered why, to solve both our issues, companies donāt just make the midi timing sample accurate. Rather than 480/960ā¦why not make it āsnapā to the nearest sample pulse? Effectively making there be no difference in the timing of sequenced midi and ālive playedā midi. Just something Iāve wondered in all these years of having less than stellar internal VI timing. While I get there will never be a true āmidi 2.0ā, why not go ahead and establish a bridge to that with the timing resolution locked to the sample clockā¦giving yet another reason to go to 96k!
I do credit the forum members with at least moderate intelligence enough to tell Iām not talking about a math concept but a variable sound reproduction process. If they didnāt have that intelligence theyād never be able to use Cubase to the full.
I may have found why thereās no nulling here! On copying the same track I did, as expected, find comb filtering. Then I panned one hard left and one hard right. The drum sounds did a nice stereo dance with toms etc. panning across the monitors.
So? What you are summing is, although it doesnāt say so explicitly, already a stereo sound field of drums and this movement is what is causing the āout of phasementā and non-nulling and why recording copies produces no nulling.
I suggest that to properly double any sounds that you perform a āDissolve partā to get the required sounds, typically mostly snare and bass drum, you might find things are rather more civilised but I suspect you may still get some phasing. Mostly though Iād expect phasing especially if you double different samples from another drum patch. Not that that isnāt mostly the typical idea of doubling ie: To get interesting phases and reinforcements and, at times, weakening a too strong signal. Phasde reversal is, after all, usually used on input from stereo mic pairs and overhead v. drumkit mics and not for checking midi signals. And even live drumkits can have undesirable phase relationships between overheads and the close-mics which can be remedied by careful phase reversal.
Unfortunately (it seems) for me, when you were talking about convolution in the context of digital audio, I did think you meant convolution in the technical sense, ie as used in digital audio.
TBH, Iāve never before known the word āconvolutionā to be used to describe a āvariable sound processā - and TBH Iām not actually sure what that might include: things like āround-robinā samples, perhaps? (used to stop repeated notes sounding too similar); phasing? flanging? free-running oscilators that donāt re-start at a particular part of a wave form when a note is triggered? the liberal use of MIDI Continuous Controllers to breathe life into samples? any live (real) instrument? ā Do all real instruments exhibit āconvolutionā (in this sense) whenever theyāre played?
Anyway, now I know Iām doomed never to be able āto use Cubase to the fullā, because I donāt have moderate intelligence (for, if I had it, I wouldnāt have thought you were using āconvolutionā in the technical sense). Fortunately for me, I donāt actually want to use it to the full - I just want to be able to use the small corner of Cubase that deals with the way I make my music, and use it to the depth required to make things sound like real performances.
BTW, as of today, Iām going to use the word ātomatoā to mean any food that isnāt green. I think anyone with at least moderate intelligence will know what I actually mean when I ask for a tomato.
āas a spasmodic chortle burst forth, Como barely managed to avoid spewing his partially masticated mouthful on the computer screenā
āWords mean what I want them to mean when I want them to mean that.ā
Paraphrasing the Hookah Smoking Caterpillar in Alice In Wonderland.
āIt all depends what āisā means.ā Quoting Bill Clinton.
Como
Please excuse me for butting inā¦ He said buttā¦
But isnāt this all getting a bitā¦ em, convoluted?
Iām still learning and I bow to the man who obviously knows it all.
Convolution is an adjective or describing word and not a noun like ātomatoā. And tomatoes can also be green.
I see you understood me. See. The forum members are intelligent as I said.
Do all real instruments exhibit āconvolutionā (in this sense) whenever theyāre played?
Yes. Thatās why theyāre hard to emulate. Sorry, synthesise (in case you thought I meant ātomatoā).
Iām a little unclear whether you are using ābuttā mathematically, as common parlance or somewhat ātomatoish?ā
Como
No difference, both have random shifts in time.
With the MIDI Monitor I did log the difference between data send on one channel (MIDI Out) and data received on the other channel (MIDI In) on 120BPM. So both logās should be the same. I did the tests several times with timestamp enabled and disabled, no difference in result though.
The result speaks for itself (observe Length and Position).
MIDI Monitor Log Midi Out (programmed):
Status Val1 Val2 Val3 Ch. Length Position Comment
======================================================================================
Note On C2 100 64 1 118.000 3.04.01.000
Note On C2 100 64 1 118.000 4.01.01.000
Note On C2 100 64 1 118.000 4.02.01.000
Note On C2 100 64 1 118.000 4.03.01.000
Note On C2 100 64 1 118.000 4.04.01.000
Note On C2 100 64 1 118.000 5.01.01.000
Note On C2 100 64 1 118.000 5.02.01.000
Note On C2 100 64 1 118.000 5.03.01.000
Note On C2 100 64 1 118.000 5.04.01.000
Note On C2 100 64 1 118.000 6.01.01.000
Note On C2 100 64 1 118.000 6.02.01.000
Note On C2 100 64 1 118.000 6.03.01.000
Note On C2 100 64 1 118.000 6.04.01.000
Note On C2 100 64 1 118.000 7.01.01.000
Note On C2 100 64 1 118.000 7.02.01.000
Note On C2 100 64 1 118.000 7.03.01.000
Note On C2 100 64 1 118.000 7.04.01.000
Note On C2 100 64 1 118.000 8.01.01.000
Note On C2 100 64 1 118.000 8.02.01.000
Note On C2 100 64 1 118.000 8.03.01.000
Note On C2 100 64 1 118.000 8.04.01.000
Note On C2 100 64 1 118.000 9.01.01.000
Note On C2 100 64 1 118.000 9.02.01.000
Note On C2 100 64 1 118.000 9.03.01.000
Note On C2 100 64 1 118.000 9.04.01.000
Note On C2 100 64 1 118.000 10.01.01.000
Note On C2 100 64 1 118.000 10.02.01.000
Note On C2 100 64 1 118.000 10.03.01.000
Note On C2 100 64 1 118.000 10.04.01.000
MIDI Monitor Log Midi In (recorded):
Status Val1 Val2 Val3 Ch. Length Position Comment
======================================================================================
Note On C2 100 64 2 116.720 3.04.01.000
Note On C2 100 64 2 116.080 4.01.01.000
Note On C2 100 64 2 115.760 4.02.01.001
Note On C2 100 64 2 115.440 4.03.01.001
Note On C2 100 64 2 115.760 4.04.01.001
Note On C2 100 64 2 116.400 5.01.01.000
Note On C2 100 64 2 115.760 5.02.01.001
Note On C2 100 64 2 116.080 5.03.01.001
Note On C2 100 64 2 115.760 5.04.01.001
Note On C2 100 64 2 115.120 6.01.01.001
Note On C2 100 64 2 115.440 6.02.01.001
Note On C2 100 64 2 116.400 6.03.01.001
Note On C2 100 64 2 116.080 6.04.01.000
Note On C2 100 64 2 115.120 7.01.01.001
Note On C2 100 64 2 116.080 7.02.01.000
Note On C2 100 64 2 116.400 7.03.01.001
Note On C2 100 64 2 115.440 7.04.01.001
Note On C2 100 64 2 116.400 8.01.01.000
Note On C2 100 64 2 116.080 8.02.01.001
Note On C2 100 64 2 114.800 8.03.01.001
Note On C2 100 64 2 115.120 8.04.01.001
Note On C2 100 64 2 116.080 9.01.01.001
Note On C2 100 64 2 116.080 9.02.01.001
Note On C2 100 64 2 116.400 9.03.01.000
Note On C2 100 64 2 116.400 9.04.01.000
Note On C2 100 64 2 116.400 10.01.01.001
Note On C2 100 64 2 116.080 10.02.01.001
Note On C2 100 64 2 116.080 10.03.01.001
Note On C2 100 64 2 115.120 10.04.01.002
So it is save to say: āOn my system***** MIDI timing in Cubase is NOT consistent!ā
Edit: *System: Asus P5WDH-Deluxe, Quad 2 Core Q6600, DDR2 PC-5300, GeForce 7900GS silent