zamrateMaybe the jitter has something to do with with the multi-core-support?
No it hasn’t. Because when you hear the notes you play during recording (which sound like in the right spot), they already have been timestamped (or at least should have been), so it’s just a matter of inserting them in the right (in my opinion same) spot afterwards.
zamrateAny forecast when this will be fixed? Ableton & EnergyXT are so far the only sequencers I tried that don’t mess up the MIDI timing..
zamrateOr to put it differently: the wave coming out of your speakers when playing it back should be exactly the same wave that came out of your speakers when you recorded.
zamrateMidi jitter I’ve seen discussed many, many times over at Gearslutz. Its a fact of life for most of us unless you can get the really good hardware and get everything synced to a good clock. I’ve even noticed different time stamps on the midi data depending on whether I use the USB port versus my midi input on my Pro40. It really is an issue that I should give more attention to.
I am not talking about the jitter or latency introduced by the hardware or the drivers etc… There is no way to get rid of it. I’m talking about sequencer-introduced jitter.
When during recording, you heard the sound of your VSTi that you played coming out of the speakers at song time T, it should also come out of the speakers at song time T again upon playback.
Some sequencers will play it back at T-k (-k being a constant negative latency) but others (like Cubase) will play it back at T-k-r , r being a random number that may vary in between a few hundred samples. So r is a jitter introduced by the sequencer, and I’d really like to know the reason for it being introduced! If you don’t believe me, do the tests.
At the time the ASIO processing picks up the MIDI events that came in, they already have been given a timestamp (by the OS or yourself), be it accurate or not, and that timestamp should be the one and only reference for the placement of the notes in the audio stream, and that placement should be the same during recording and playback. This has nothing to do with factors such as USB latency/jitter, soundcard quality etc. The timestamp of the event MUST be the one and only reference and it should be used as sample-accurate reference in a good sequencer. If it was heard at sample X in the song during recording, it should also be heard at sample X during playback. Period.
zamrateif you don’t believe me, try putting the same bass drum sample sample-accurately over each other, and compare to the same bass drum sample “set over each other” with the second bass drum sample having a delay of 1 ms compared to the first bass drum sample. you’ll hear the difference, trust me – and with some dynamics (Compressor) added to the whole, you’ll hear the difference even more.
zamrateVery easy to do this MIDI playback vs. recording jitter/latency test with Podium or any other app, but you need a soundcard with an internal input (like my Delta1010LT’s “monitoring input”):
1) In Podium, on a first track put a short click sound on every beat of one bar and set your latency to let’s say 128 samples with ASIO driver
2) In Podium, loop that bar at 125 BPM
3) create another track with a VSTi that has sample-accurate timing (!!) (I used Discovery2, but there are many synths that not have sample-accuracy, so watch out)
4) In Discovery2 make a high pitch short sawtooth sound that also sounds like a short click (Attack set to 0)
5) Now, load a audio recording app, such as Cool Edit and start recording the virtual input of your soundcard (so you start recording what comes out of Podium actually)
6) Back in Podium, put on REC and Press Play, so you now hear your audio click playing which you let play for one bar. After the start of the second bar play Discovery2 notes between the audio click for one bar, so you have: click, note, click, note, click, note, click, note. Still let play Podium one bar (so it plays the bar you just recorded) then press stop.
7) Back to you audio editing app now which recorded the audio: Delete everything from the beginning of the recording until the start of the first click of the “recording bar” where you started hitting/recording notes. Also delete the right channel’s waveform (everything is then zero on the right channel). Now cut the “playback bar” (the one podium was playing directly after you recorded your bar) audio on the left channel and put it at the start of the right channel SO THE 4 CLICKS MATCH SAMPLE-ACCURATELY ON LEFT & RIGHT CHANNEL NOW (USE ZOOM TO CHECK!).
8 ) Still In your audio editing app, check the distances between the 4 recorded notes and the 4 playback notes. Just as the 4 reference clicks do match, the notes should also match because what you heard during recording should also be what you hear during playback, no matter what any person might tell you. It is the only way you can achieve what you want.
Here’s a reason why what you heard during recording should match what you hear during playback: if during playing/recording a drum groove in a looped bar, you thought: “wow that was a good groove” and then playing it back your drum groove notes are suddenly not placed exactly like you heard them played at recording time, then it’s frankly impossible to ever achieve what you want – it will in that case be more or less a matter of luck if the final result is what you wanted or not. For drums, even 1 ms displacement (earlier or later) makes a difference sometimes, and 1 ms is “just” 44 samples @ 44.1kHz sample rate!
zamrateFrits, I did some further research on the subject and the results I got are more than worrying.. Can’t believe my own eyes:
Out of 3 commercial “big boys”, only one sequencer has no midi recording jitter (on the sequencer side! ofcourse windows’ own jittering is always involved but that’s the case for everybody) and sample-accurate midi recording (sample accurate = note starts at position it was heard when playing the keyboard while recording).
– worst was presonus studio one (completely off way, not usable, but they know it and are working on a fix if i believe their forum)
– 2nd worst was cubase sx 3 (100 samples jitter + 400 samples off timing… – who would have thought it? such as classic is not even able to record midi properly! shame on steinberg!)
– 3rd worst of the 4 i’ve tested was podium (see results above)
and the only sequencer (of those 4) which did do the job well was ableton live 7 – 100% sample-accurateness.
FYI tests were performed at 128 samples latency on windows xp.
PS: Also checked FLStudio 9 now. Interestingly FLStudio has not jitter, but a constant negative delay (notes come too early after recording) of 588 samples. but even that constant delay is very bad. and i don’t see why flstudio is putting everything 588 samples (= much more than ouput latency of 128 samples) back. weird.
zamrate>How did you make the recording of the realtime monitoring vs. playback?
I just used my Delta 1010LT Monitoring Input (sent you the WAV via email, did you get it?) and recorded that one in Cool Edit. I pressed record and play in podium while having a Audio Loop as reference. Then I played the notes during the recording of one bar and let podium play the same bar another time. Then, in cool edit, layed the second bar “under” (on the second channel) the first bar, adjusted them for the beat samples to be 100% aligned to each other and then I checked the sample offsets of the midi notes.
>Is the latency/jitter the same with different VSTi’s? Some instruments may have an internal buffering where they process notes and LFO’s etc. at certain sample intervals, for reasons of CPU optimization. The fact that a constant latency is added for the realtime monitoring may cause the notes to fall in different processing intervals within the synth, resulting in jitter.
I used Discovery2 VSTi. I specifically tested if it this synth is 100% sample-accurate and it is (at least as exact as 4 samples sample-accurate).
If my procedure would not have been accurate, I could not have verified that my sequencer is sample-accurate anyway.
zamratewell, you say the jitter is “minimal”, but there should not be any at all. as we see in my case there was 217-160 = 57 samples jitter. That’s quite considerable, so why do you say it’s minimal after i took time to collect and present you this data?
If the delta amount of samples of 1st note 2nd note 3rd note and 4th note would have been a constant of 128 samples (size of asio input buffer), there would have been 0 jitter and i’d say ok – it’s a philosophical question wether you want to have the incoming events played with the input latency of the soundcard added and at playback time notes played without the input latency of the soundcard. but having a jitter is just cheap and i even can’t understand why it is introduced, because at the time you get your midi messages (before even hearing them play), they have been given a timestamp (by your code) and so where does the jitter come from anyway?
believe it or not, i made this midi-timing test because i was hearing with my own ears that something was wrong when the midi notes were being played back after recording. the timing is really bad! i think that if my ears can notice it, you should maybe reconsider your position.
as i previously said, in my mini-sequencer, there is 0 samples jitter and 0 samples difference between played and recorded midi notes (and it just sounds “right” to my ears, too). if you want i can send it to you, so you can do some tests and then choose for yourself what’s better.
zamratebecause I tend to cut my beats into 1/16th notes. And in this case I had a bassdrum following another one the 1/16th note behind. I wanted the 2nd bassdrum to be extracted to copy it on some other place. As soon as I had sliced the beat I noticed a difference in sound. Ofcourse I could have merged the 2 parts back again at the slicing point after having copied my 2nd bassdrum somewhere else, but I think the sound should not change when you slice something anyway..
zamrateWell, first of all, the user should not care about this. In other hosts, such as Cubase (and believe me, I’m not a big Cubase fan!), there is no such click when you cut at some position being in Bar/Beat resolution, so it shouldn’t be the case in Podium either, don’t you agree? 😀
Also, even if internally your code uses a resolution 16Bit/Bar (which is more than enough anyway), and you get fractional sample positions resulting from it (and you don’t use any kind of interpolation, which is good by the way), you could still fill a possible one-sample or two-samples gap with an average value or ‘line’ between the last sample and next sample. Otherwise you’ll hear clicks and nobody wants that.