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/10 09:01:42
(permalink)
ORIGINAL: pianodano
Maybe I'm missing something here but that's exactly what I think should happen if you are aiming for say... the exact beat. But I don't think improved acurracy is the correct term if you're intentionally playing behind the beat and want exactly what was played captured.
It stands to reason, ALL midi is quantized to one tick or another. More ticks should equal capturing with higher accuracy the original performance. Whether the orginal performance was accurate or not is another matter entirely and, in my mind, a poorly timed performance is what quantization is used for, traditionally.
Yes, I think you're missing something. 1. Record audio and midi at the same time from a external synth. 2. Print that midi onto another audio track. 3. Compare the first audio track with the other (after lining up the first sample). The audio recording made in step 1, which is not quantized, is what we're trying to duplicate with the midi. If the midi is recorded at 96ppq, the audio samples recorded in steps 1 and 2 will line up much more closely than if the midi is recorded at 480ppq. Again, the recording is simply 8th notes (very few bytes running through the port)
|
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/10 09:36:26
(permalink)
ORIGINAL: dstrenz
ORIGINAL: pianodano
Maybe I'm missing something here but that's exactly what I think should happen if you are aiming for say... the exact beat. But I don't think improved acurracy is the correct term if you're intentionally playing behind the beat and want exactly what was played captured.
It stands to reason, ALL midi is quantized to one tick or another. More ticks should equal capturing with higher accuracy the original performance. Whether the orginal performance was accurate or not is another matter entirely and, in my mind, a poorly timed performance is what quantization is used for, traditionally.
Yes, I think you're missing something.
1. Record audio and midi at the same time from a external synth.
2. Print that midi onto another audio track.
3. Compare the first audio track with the other (after lining up the first sample).
The audio recording made in step 1, which is not quantized, is what we're trying to duplicate with the midi.
If the midi is recorded at 96ppq, the audio samples recorded in steps 1 and 2 will line up much more closely than if the midi is recorded at 480ppq. Again, the recording is simply 8th notes (very few bytes running through the port)
Yep. I do that all the time but not a 96. I am after capturing the performance with more accuracy as oppossed to a quantized performance. We are both saying the same thing but in different ways. Must be a failure to communicate on my part. 
post edited by pianodano - 2007/10/10 09:40:00
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
|
Nick P
Max Output Level: -44 dBFS
- Total Posts : 3112
- Joined: 2006/09/01 18:08:09
- Location: Area code 392 - Arlington Hts, IL
- Status: offline
RE: MIDI "Jitter" - It Does Exist
2007/10/10 12:12:57
(permalink)
True, all MIDI is "quantized" to some degree. But on a philosophical level, all audio is "quantized" to some degree, if we consider that time itself could be "quantized" at the atomic level. What we are talking about is the human ear's capability to perceive different timing anomalies and/or "feels" of musical performances, whether the ear is that of a trained musician or a lay person.
Nevertheless, for the purposes of traditional discussion about MIDI, "unquantized" means played back as performed at whatever clock rate is default by the sequencer or set by the user in the case of software which allows this setting. "Quantized" means imposing time correction using the software such as eighth, sixteenth, thirty-second, etc... notes.
(I realize you most likely know all this)
What we are talking about is what we hear back versus what we play in. It's that simple. Theoretically if we play in audio and do not deceive ourselves, we should hear back exactly what we play. However I wonder now if even audio can be altered via the I/O process invoked by a computer-based recording solution. And theoretically with MIDI, we should hear back very close to what we played in, assuming a high enough clock rate (PPQ), which is obviously the subject of a good deal of debate exactly how high that must be.
However many people (note the number of posts in this thread) believe that the process of the computer (as opposed to a hardware MIDI sequencer) receiving, processing, and playing back MIDI data imposes a certain amount of imperfection into the MIDI performance (which we are calling "jitter" for lack of a better term). The degree and amount of this "jitter" is the subject of this thread. Much of it is based on many of us having experienced and sensitive musical ears enough to hear this without scientific measurement. Does this make our findings subjective? Of course. However notice that many users have and continue to take scientific measurements via audio editors now commonly available.
Bottom line: We think MIDI "jitter" exists, and many of us feel it is enough of a problem to warrant investigation by both designers of DAW software, as well as operating system designers such as Microsoft. Obviously the folks at Ableton agree, hence the impetus to start this thread upon reading about their new product Live 7.
Cakewalk Forums - A Great Learning Resource For All Things Cakewalk!
|
space_cowboy
Max Output Level: 0 dBFS
- Total Posts : 9813
- Joined: 2007/07/20 14:49:31
- Location: Front and center behind these monitors
- Status: offline
RE: MIDI "Jitter" - It Does Exist
2007/10/10 13:25:16
(permalink)
OK I havent read every single post here so I run the risk of saying what others have said.
I believe a studio needs a master clock that everything is tied to. I have an Apogee clock in my D8B that is the master for my MIDI and for my audio.
I dont know about MIDI jitter but you do run the risk of things not being in sync exactly right if you have multiple clocks going on. There is a clock for midi, a clock for audio and there are probably others out there. I used to get things that never seemed to sync up exactly right when I didnt have one master clock.
Some people call me Maurice SPLAT Pro lifetime, ADK 6 core 3.6Ghz with 32 GB RAM, SSD 1TB system drive, 3 3TB regular drives for samples, recordings and misc. Behringer X Touch, UAD Apollo Quad. 2 UAD2 Quads PCI (i think - inside the box whatever that is), Console 1. More guitars (40??) and synths (hard and soft) than talent. Zendrum!!!
|
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/10 14:45:31
(permalink)
I stated this several times in the thread already, but at the risk of sounding repetitive.... It does make sense that a lower midi resolution would be tighter. The reason is very similar to why larger audio buffers reduce audio glitching. The system can keep up with things better. Its probably not necessary to go all the way down to 96ppq, but I personally think 240ppq is the magic number on windows. The fact is that the windows timer can't accurately record 960ppq, even at its most optimal. At 120bpm, 960ppq = 0.5ms/tick. The Windows MM timer is 1ms by design, but often does not achieve even that. 960ppq is a complete pipe dream at 120bpm. 480 is the theoretical best it can do(1ms ticks). 240 is more realistic. 240 = 2ms/tick. However at slower tempos, then the higher resolution becomes more meaningful. For example, at 60bpm, double everything. For example, at 60bpm, 960ppq=1ms/tick. So I might prefer 480ppq at 60bpm vs 240ppq at 120bpm, but I would expect them both to be giving me about 2ms/tick, which is enough time for the Windows OS to be more reliable about the MM timer. If you have hardware midi timestamping you might be able to record better than 1-2ms precision reliably, but you better plan on not using soft instruments to monitor what you're playing if you expect to make effective use of that resolution in some way. Yes a low resolution does have some inherent built in quantizing...similar to input quantize...but let me breakdown some of the resolutions and the quantization they represent.(I had it wrong earlier):
PPQ equiv quantizing
----------- -------------------
48 128th triplets
96 256th triplets
120 ~512ths
192 512th triplets
240 ~1024ths
480 ~2048ths
960 ~4096ths
( note that some of them have a tilde(~), which means that resolution does not divide evenly into 4/4 time musical values. For example a PPQ of 128 instead of 120 would give exact 512th note resolution. The reason sequencers use 120 is related to midi clock which divides up each beat into 24 pulses. So PPQ's always have to be a multiple of 24. However, the lower resolutions all land in good places and when you start talking about 512th notes, the musical timing division is not really applicable anymore.) I would argue that when someone is trying to play in the groove at 96ppq, they might still be landing on even ticks at that quantization level. Otherwise everyone in the industry would have been totally disenchanted with the MC500 series of hardware sequencers. But we all know that many a pro keyboard player that was head over heels in love with that box...so apparently 96ppq is actually plenty of resolution to capture a groove. Even the infamous MPC line, only the latest top of the line model has 480ppq. All the rest of them are 96ppq. What I have heard from a few is that higher resolutions are needed to capture the exact nuances of note clusters, grace notes and things like that. What that means is that for those odd times when you have a grace note or cluster or something...using a low ppq may sound kind of clunky, but this is a different thing than the timing jitter that most people might be complaining about. The timing jitter has more to do with how well the performance "grooves". Lower PPQ is more likely to be be able to be handled reliably by the poor Windows timer and for grooving purposes, I don't think the higher PPQ's are adding any benefit. Furthermore, even if you do try to use the higher PPQ for capturing your grace notes...Windows OS might still intercede a 1-2ms jitter anyway, which could still make those things sound clunky. Regarding Ableton Live. The report is that they improved midi timing from what it was before. We do not know how good or bad it was before. There is a theoretical limit to how good they can make it...which we have discussed....related to the Windows Operating system. Are they at that limit? Is Sonar at that limit? I don't think we know for sure. But I will say that I think Cakewalk has been known for having some of the best midi timing on DOS/Windows for YEARS. They have always been good about getting their sequencers as close to the limit of what is possible on DOS/Windows. Live on the other hand started out as mostly an audio looping program and then added midi little by little. My guess is that their first midi implementations were a bit flawed and possibly had horrendous timing problems that needing fixing..which apparently now they have done. But I am only guessing. They still have the same OS limit and there is nothing anyone can do to beat it or they all would have done it already. The OS limitation is just there. On the other hand, I am much more suspicious that Sonar may have some bugs or design problems related to freezing and mixing down midi tracks through soft synths, or bugs in delay compensation or something like that, based on some of the feedback we have heard here.
post edited by dewdman42 - 2007/10/10 15:14:40
|
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/10 15:02:30
(permalink)
ORIGINAL: Nick P
However many people (note the number of posts in this thread) believe that the process of the computer (as opposed to a hardware MIDI sequencer) receiving, processing, and playing back MIDI data imposes a certain amount of imperfection into the MIDI performance (which we are calling "jitter" for lack of a better term).
A little more clarification about this. One of the reasons that Audio can be recorded by your PC, essentially jitter free, is because there is dedicated hardware(ie, soundcard) that uses its own internal clock to capture the audio and save 44,000 samples per second into a buffer. The catch here is that the actual timing of collecting that audio and storing as timestamped discrete values is done in the soundcard hardware. The Windows OS then comes back every so often at its own good pace and grabs chunks of data from the buffer. This is why if you have a larger buffer, you are giving windows more time to do whatever it needs to do and come take from the buffer as much as it can. Meanwhile, the dedicated soundcard hardware is just clicking along like a machine, sampling the audio and stuffing it into the buffer. It has only one task to do and will do it accurately. With midi, for most people...the timestamping of the midi events is not handled by hardware, its handled by software, which means it has to wait in line with everything else the Windows OS is trying to do. The midi interface receives midi events and stuffs them into a buffer, just like audio, and it will fill up that buffer with as much as it can until the Windows OS will get around to coming and getting what is in the buffer. But the difference is that the midi events do not get any timestamps until Windows comes around to fetch them from the buffer. From Windows perspective, whatever is in that buffer at that time gets the same timestamp, even if the events came into the hardware at different times. See what I mean? This is why hardware timestamps are really needed. Further to all that, Because are often using a midi keyboard to control a soft synth, you sorta don't want the Windows OS to take too much time before coming to get stuff from that buffer, because otherwise you'd have big latencies. You need a realtime response for midi. Essentially, with midi you need the equivalent of really really small audio buffers. But the problem is that the Windows OS just does not provide much better than 1-2ms via the MM timer.
|
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/10 15:31:04
(permalink)
Dewdman42, Thanks for those posts but I really have a few questions now please. At the risk of me sounding like a complete dummy, you're saying that the audio sample rate is not divided down to achieve the midi ticks? On a machine that can do nothing but handle numbers ? And if that is the case what is the common link tying audio and midi together? And, why wouldn't all data, audio or midi just be spit out in consecutive track order ? Also, as I mentioned many posts back, and again I agree, the MC500mkII (I have mine on the shelf and have owned it since it was introduced around late 87, or early 88) was as good as it got then imo but I should add that it can not handle the metadata and volumes of sysex and continuous controller events spit out by todays keyboards. But YMMV. The Motif and Tyros I have, in contrast, run at 480ppqn.
post edited by pianodano - 2007/10/10 15:43:07
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
|
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/10 15:36:35
(permalink)
A couple of quick points.
96 ppqn gives a time resolution of about 5.2 msec at 120 bpm. That's 5x coarser than the 1 msec nominal resolution of the Windows MM timer. So, even if the time values jitter around a bit on playback, the jitter will be less than the "inherent quantizing" that's imposed by the 96 ppqn sequencer resolution. Net result: audible playback should be much more consistent from one time to the next, because any jitter effects are 'swamped out' by the lower ppqn.
Is 960 ppqn useless? That depends. A DirectMusic (DM) driver can accept high-res timestands (in microseconds, I think, rather than milliseconds). If the DM driver is for something like a MOTU time-stamping MIDI interface, the 960 ppqn time value will be translated to a MIDI timestamp with a resolution of 1/3 millisecond (per the MOTU timestamp protocol). If the DM driver is for something like a Firewire MIDI interface, you might also get time resolution around 1/3 millisecond (because Firewire MIDI can do that, assuming no MIDI-logjam effects -- a big IF, to be sure).
Of course, if the 960 ppqn time value is being used by a soft synth - it may be translated to a sample-accurate time value. That's one big reason why, say, EZ Drummer drums can sound amazingly tight / in the pocket. The source data is a MIDI pattern from the EX drummer library (or GrooveMonkee); the MIDI data is played back directly through the EZD soft synth, and the MIDI data never comes anywhere near the Windows MIDI driver stack on your DAW.
- Jim
|
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/10 15:47:44
(permalink)
There's a test someone might be interested in trying (I don't have time right now, unfortunately -- just enough time to kibitz a bit  ) Create a new Sonar project. In the PRV, draw in an ascending scale - say, 16th notes. Keep the note durations short -- say, 50% of the duration to the next note. Now, connect a MIDI cable from a MIDI output to a MIDI input. Route things so that you can re-record the MIDI output onto another track. Now, play back the sequence you entered manually in the PRV, and record it onto another MIDI track. Look at the two tracks. How well do events in the two tracks line up? How well-spaced are the events in the 2nd track? How even are their durations? Does it make a difference if you insert an empty bar before the first note of the ascending scale? Try it again, at a different sequencer resolution (say, 96 ppqn). You should do this with a brand new project. Do events in the two tracks line up any differently? Differences between the two tracks ought to indicate the amount of 'round trip' error in your MIDI subsystem. The re-recorded event has made two trips through the driver stack -- once going out (during playback to the physical MIDI cable) and once coming back in (as they are recorded into the 2nd MIDI track). Of course, when you record from a MIDI keyboard, the round-trip occurs in reverse (first going into the DAW, then coming back out, if you're using an external sound module), but the total amount of MIDI "handling" by the MIDI subystem (MIDI interface driver/hardware and Windows MIDI stack) should be about the same. If you give this a try, please post your results on this thread. And let us know what MIDI interface(s) you used. Thanks - Jim
|
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/10 15:59:38
(permalink)
If you like to mess with electronics, you can actually capture the MIDI data (coming out of the MIDI DIN ports on your interface) as audio data. Why would you want to do that? So you can measure it pretty accurately (~22 microsecond accuracy with a 44.1K sample rate). For details on the basic approach, see this CNMAT paper: http://cnmat.cnmat.berkeley.edu/ICMC97/papers-html/Latency.html The CNMAT approach is sound (especially for capturing Ethernet events), but you can capture MIDI messages as audio more easily, if you're willing to hack up a MIDI thru box. Every MIDI input circuit uses an opto-isolator to convert the incoming current-loop signal into a voltage signal that is ground-isolated. To use this voltage - locate the pin on the opto-isolator that presents an AC signal when you apply MIDI to the corresponding DIN input jack. (An oscilloscope is useful here). Then, solder on a 2K or 10K resistor to this pin. Connect the other end of the resistor to an audio jack (1/8" jack works for me). Then, plug a cable from that jack to an audio input on your DAW audio interface. Congratulations! You've just created a MIDI-to-audio transcoder! Since the MIDI signal is a weird-looking pulse train with a fundamental frequency of about 15.75KHz, you can record it just like audio. Now -- if you repeat the ascending-scale experiment in my last post -- you can capture the outgoing MIDI data directly as audio (recording it to another track in Sonar). Then, you can see just how badly the outgoing MIDI data gets time-skewed. The advantage here is that you can see what the jitter/latency is like for one-way MIDI transport (outgoing only). With the approach above (using a MIDI cable to 'loop back' the MIDI out to a MIDI in) - you can only look at at the total roundtrip jitter & latency (outgoing + incoming). - Jim
|
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/10 16:05:49
(permalink)
|
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/10 16:07:45
(permalink)
Another very interesting article about tempos and PPQ I just stumbled on: http://midistudio.com/Management/R-Finley/q&a.htm This guy says the following, which is intersting as related to that ~ comments I made above:
Any sequencer resolution has quantisation error of its PPQN clock tick delay rate. It is not the same as, although similar too, duration quantisation, but occurs at the lowest MIDI bandwith data rate level which the sequencer used, not for transmission, which is absolute, but for recording and playback.
I do not recommend using PPQNs of 120, 240, 480 or 960 because of the "inhuman" feel which the factor of 5 introduces to such quanitisized recordings.
Q:Why would these resolutions (do you mean resolutions or tempos) not be satisfactory and would (I think Cakewalk goes up to a maximum speed of 240) produce an inhuman feel?
A: Human swing feels are based on factors of 3. Whereas straight feels are based on factors of 2. In my opinion ALL other rhythms are "felt" as multiples of the factors of 2 and 3 only. "One" being a common factor to anything.
Q:What is significant about the factor 5? Why would other resolutions or tempos be better?
A: Resolutions which use factors besides 2 and 3, introduce a quanitisation error at the recording level in my opinion which is not inherent in human performance.
I take that to mean that 192ppq is preferable to 240. Or 384 instead of 480. I'm still trying to figure out what he means by factor of 5. Anyway, interesting reading...
post edited by dewdman42 - 2007/10/10 16:26:30
|
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/10 16:22:53
(permalink)
"factor of 5' has to do with quintuplets. 240/5 is exactly 48. (240/3 is exactly 80).
192/5 is 38.4, while 192/3 is exactly 64. The person recommending against 120, 240, 480 or 960 ppqn -- seems to think using these PPQN values would tend to subtly quantize everything toward a quintuplet feel, rather than towards a triplet feel.
Yeah, right. What about swing feels that aren't locked to exactly to a 2.000:1.000 ratio between on-beat and off-beat accents? What about country grooves that play just a bit ahead of the beat? What about all kinds of other grooves, with all kinds of different fine-grained pulse structure? Personally, I don't buy it.
- Jim
|
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/10 16:32:38
(permalink)
ORIGINAL: pianodano
you're saying that the audio sample rate is not divided down to achieve the midi ticks?
correct.
And if that is the case what is the common link tying audio and midi together?
The system clock. Your computer knows the number of milliseconds since 1970 at any given time it is asked. It knows finer resolutions than that..you can start a timer and then later on ask how many since. Audio is handled as number of samples since starting at a known sample rate. Midi is handled as number of "ticks" since starting..where a tick depends on your PPQ and tempo. They each manage themselves independently beyond that. When you are using an internal audio clock, that is not the midi clock. That is internal word clock vs external word clock..which is an audio only thing. The Midi clock is the ticks we've been talking about.
And, why wouldn't all data, audio or midi just be spit out in consecutive track order ?
I don't understand this question
The Motif and Tyros I have, in contrast, run at 480ppqn.
How do they compare to the MC500 in terms of your midi recording and playback experience and timing?
|
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/10 18:08:08
(permalink)
ORIGINAL: dewdman42
ORIGINAL: pianodano
you're saying that the audio sample rate is not divided down to achieve the midi ticks?
correct.
And if that is the case what is the common link tying audio and midi together?
The system clock. Your computer knows the number of milliseconds since 1970 at any given time it is asked. It knows finer resolutions than that..you can start a timer and then later on ask how many since. Audio is handled as number of samples since starting at a known sample rate. Midi is handled as number of "ticks" since starting..where a tick depends on your PPQ and tempo. They each manage themselves independently beyond that. When you are using an internal audio clock, that is not the midi clock. That is internal word clock vs external word clock..which is an audio only thing. The Midi clock is the ticks we've been talking about.
And, why wouldn't all data, audio or midi just be spit out in consecutive track order ?
I don't understand this question
The Motif and Tyros I have, in contrast, run at 480ppqn.
How do they compare to the MC500 in terms of your midi recording and playback experience and timing?
Thanks for taking the time to explain. A well timed smooth gliss (like would hear or do on a Hammond) or fairly uptempo grace notes a la Floyd Cramer should demonstrate the difference as far as 96 vs 480 ppqn. The MC500MKII was a wonderful piece of kit. Expensive at the time but worth it for the serious recordist or performer. The MKII is the 8 track version. It has 2 outs so you really could have 32 parts going. I used it until modernizing my keyboards in 2002. It was a joy to use and blazing fast for editing tracks or entire songs. Failsafe and crashproof. That piece of harware is the primary reason I have such a hard time wrapping my head around the current crop of midi problems. Sorta like a giant leap . . . . in the wrong direction. The on board sequencers such as is on the Motif xs or Tyros are easy to start a midi recording on. Just hit record. Extremely accurate. NO fun at all to do edits on. That's why I usually start a outline on one of them and then open the file in Sonar. I have found that there's evidently just too much data in the pipe when trying to play a entire songs data into Sonar or the computer. You get the idea.
post edited by pianodano - 2007/10/10 18:30:42
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
|
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/10 19:31:15
(permalink)
original: pianodano
At the risk of me sounding like a complete dummy, you're saying that the audio sample rate is not divided down to achieve the midi ticks? On a machine that can do nothing but handle numbers ? And if that is the case what is the common link tying audio and midi together? Just to add a bit (ok, more than a bit) to what dewdman42 said -- Typically, each MIDI port has an internal timer associated with it. Timer value '0' refers to the exact instant when the MIDI port was opened. That internal timer counts up from 0, in milliseconds, or microseconds, or some other unit depending on the MIDI port driver. There are at least two main kinds of 'system timer' -- the 1 millisecond-resolution "MM Timer" and a much-higher-resolution counter intended for use to measure things like CPU execution times for assembly code fragments (in some systems this is 'QPC', in others 'RDTSC'; some systems might have both). Dual-core systems - might have two different high-res timers, which might not be kept in sync (this screwed over some game developers big-time). If you're lucky, all the MIDI ports will reference the same internal clock. Otherwise, they will drift over time with respect to each other. So - what is the common link tying audio and midi together? Think about the 'clapper' used in film making, to tie audio and video together. This is the classic bit where a gofer claps the top and bottom parts of the 'clapper' board together. This combines a loud sound and a clear visual impact. Later, the production house (film or audio editor) uses this to sync up the field audio recording and the actual camera footage. Similarly -- when you click Start on a sequencer --- the sequencer checks the current free-running audio driver sample count and current free-running MIDI port timer value, and equates them to 'Sequence tick 0' (assuming you're starting from the top). Let's say you click 'Start' at exactly 10 pm tonight EST. The wallclock time is 22:00:00 EST. The sequencer tick position is 0. The midi timer value at that instant is 33145 (assuming a millisecond count, and that the sequencer opened the port about 33 minutes ago). The audio driver sample count at that instant is 322953421 (example). Now, assume that the sequencer has previously measured the rate at which each timer (system, midi, audio) increments, relative to each other. As the sequence plays (moving ahead from tick 0) - the sequencer has to do lots of math to figure when to schedule particular MIDI events so that they happen more-or-less at the right time, relative to the audio stream. Tempo changes make this more complicated, as you can imagine. In most systems, things are directly or indirectly sync'd to the fundamental audio sample rate -- but this sync can be 'fuzzy', with adjustments being made constantly to the nominal MIDI time (MIDI port timer count value) that is guesstimated to be equivalent to a particular audio sample count value. Systems don't generally jerk around the audio playback, because this tends to produce audible glitches. Except, of course, for systems that do neat timewarping tricks with audio -- Live, for example, or Acid, or Sonar, or many others. Bottom line: sync between MIDI and audio is totally up to the sequencer.... except that it's not, because the sequencer has to depend on accurate time values being reported by many things: the PC system clock, every MIDI driver you're using, every audio driver you're using ..... all of which may be running different timebases. It's enough to make a software developer nuts!  -- a sacrifice we're willing to make for art, of course - Jim
|
...wicked
Max Output Level: -1.5 dBFS
- Total Posts : 7360
- Joined: 2003/12/18 01:00:56
- Location: Seattle
- Status: offline
RE: MIDI "Jitter" - It Does Exist
2007/10/10 19:37:06
(permalink)
Wow, this topic is blowing my mind a little bit. "transcoders"? Holy moley!
I stumbled onto this because I was recently noting that my MIDI sequences are a little loosey goosey. When I play along to a step-sequenced drum part I get a little bit of disconnect on playback and vice-versa.
I was going to ask about a possible solution, and this topic seems to have loosely generated 2:
1: use a slightly lower PPQ setting
2: get a master clock
Is this accurate? I'd love to hear about other ways to tighten up my MIDI. Now that I've got a pretty fast machine I keep stuff in MIDI a little longer than usual because the computer can handle the soft-synths. Should I not be doing that?
=========== The Fog People =========== Intel i7-4790 16GB RAM ASUS Z97 Roland OctaCapture Win10/64 SONAR Platinum 64-bit billions VSTs, some of which work
|
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/10 19:57:21
(permalink)
I stumbled onto this because I was recently noting that my MIDI sequences are a little loosey goosey. When I play along to a step-sequenced drum part I get a little bit of disconnect on playback and vice-versa.
Can you please tell us a few more specifics about the behavior you are experiencing? 1 - You are step recording? 2 - Are you quantizing the midi tracks or step entering them to a grid and then hearing them play back loose? 3 - What are the tracks playing through? VSTi in sonar or something else. If in sonar, which VSTi exactly can can you describe the midi and audio routing? 4 - Do you hear the same loosey goosiness both during playing back midi tracks and/or after you freeze the tracks or mixdown the project?
1: use a slightly lower PPQ setting
I personally think you should use the lowest PPQ that you need. Figure out how much you need and don't use more than that. If you are step entering your notes as quantized, then you need hardly any PPQ. The lower the better.
2: get a master clock
Master clock? If you are thinking about word clock generator, that is not applicable to midi. That is audio. I have heard in the past some people used to use their Miditimepiece as the master midi clock and had their Mac's slave to it. But that could be a composer's wife's tail... I think if you want truly tight midi timing the best thing is to get a hardware sequencer, preferably one that will let you load samples into it..such as the MPC or Roland Grooveboxes.
However, my feeling is that Sonar and other DAW's ought to be able to create absolutely 100% tight tracks if you are quantizing it or step recording it and playing through plugins inside Sonar. If not, then we need to scream and scream until Cakewalk fixes it. There is no technical reason for it not to be 100% tight that way.
post edited by dewdman42 - 2007/10/10 20:27:01
|
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/10 20:06:25
(permalink)
There's a test someone might be interested in trying (I don't have time right now, unfortunately -- just enough time to kibitz a bit)
Create a new Sonar project. In the PRV, draw in an ascending scale - say, 16th notes. Keep the note durations short -- say, 50% of the duration to the next note. Jim, I did almost exactly this, a bit earlier in the thread. Check that post for details of how I tested. What I concluded then was that the mean round-trip delay was about 6-7ms, and the standard deviation of the variability in when the event logged in vs. the mean "lateness" was .5 to 1ms, depending on the clock rate. At the time, I had run tests at 960 and 96 PPQ with comparable results. I have since run another test at 240PPQ, and the three tests together reveal an interesting trend: Higher PPQ results in higher mean round-trip delay, but lower jitter. I looked at both the StDev of the variation and the absolute worst-case values for jitter (i.e. difference between actual time and expected time of event arrival less the mean delay), and they agreed well. In all cases, the worst case jitter was about 2.5 to 3 times the standard deviation of individual variations, as I would expect. Here's a table (all values are milliseconds): PPQ Delay StDev Max Dev. 960 3.48 .49 1.25 240 3.16 .60 1.56 96 2.73 1.04 3.13
|
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/10 20:15:03
(permalink)
Incidentally, I discovered an interesting factoid during this testing:
When you change to a lower clock rate, Sonar has to "quantize" some of the tick values to the lower resolution. I think it's been suggested herer that this is a permanent loss of resolution. But it appears to me that Sonar is storing the original value in a different form with more resolution, because if you change back to the higher clock rate, the "odd" values come back. For example if an event happened on tick 19 at 960PPQ, it will round to tick 5 when you drop down to 240PPQ, but when you change back, you get the 19 back, not a 20 as you might expect. This opens up a whole other ball of wax about how Sonar stores event times. At lower clock resolutions, at least, it appears to be using more internal resolution than it displays.
|
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/10 20:18:59
(permalink)
Wow! Very interesting.. ORIGINAL: brundlefly
Incidentally, I discovered an interesting factoid during this testing:
When you change to a lower clock rate, Sonar has to "quantize" some of the tick values to the lower resolution. I think it's been suggested herer that this is a permanent loss of resolution. But it appears to me that Sonar is storing the original value in a different form with more resolution, because if you change back to the higher clock rate, the "odd" values come back. For example if an event happened on tick 19 at 960PPQ, it will round to tick 5 when you drop down to 240PPQ, but when you change back, you get the 19 back, not a 20 as you might expect. This opens up a whole other ball of wax about how Sonar stores event times. At lower clock resolutions, at least, it appears to be using more internal resolution than it displays.
|
...wicked
Max Output Level: -1.5 dBFS
- Total Posts : 7360
- Joined: 2003/12/18 01:00:56
- Location: Seattle
- Status: offline
RE: MIDI "Jitter" - It Does Exist
2007/10/10 20:28:48
(permalink)
ORIGINAL: dewdman42
Can you please tell us a few more specifics about the behavior you are experiencing?
Sorry dewdman, I was just writing off the top of my head. I'm not in front of the DAW right now, but I'll try and verbally re-create: + TTS-1 (piano) + NI Battery 2 + Broomstick Bass + VS3 w/guitar patch I played a piano part in to the metronome. It sounded good on playback (to the metronome). I step-entered some drums from battery 2. Sounded not so good on playback. I played the drums in by hand in Battery 2, sounded better. I selectively quantized the kik and snare, it sounded awful. I then went and hand-moved the drum hits in the PRV. Of note here was the PRV was showing notes OFF the beat lines, even ones I quantized 100% and even ones I step-entered. Moving them even further away started getting some timing back. Thinking this was odd, I double-checked my piano part. Pretty tight to the grid. I played everything else in by hand for 8 measures to test. It got a little loose after a while... meaning looser than what I know I played in. I thought maybe it was too much MIDI, so I bounced everything down. Sounds kind of choppy. Still don't have a solution. I was just going to re-sequence and try keeping everything as tight to the grid as possible and bouncing down to see if PDC might have something to do with it.
=========== The Fog People =========== Intel i7-4790 16GB RAM ASUS Z97 Roland OctaCapture Win10/64 SONAR Platinum 64-bit billions VSTs, some of which work
|
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/10 20:35:00
(permalink)
Of note here was the PRV was showing notes OFF the beat lines, even ones I quantized 100% and even ones I step-entered. Huh, what??? I'd be interested in seeing *that* MIDI file. Care to share? brundle-fly@hotmail.com
|
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/10 20:48:24
(permalink)
ORIGINAL: ...wicked
I played a piano part in to the metronome. It sounded good on playback (to the metronome). I step-entered some drums from battery 2. Sounded not so good on playback. I played the drums in by hand in Battery 2, sounded better. I selectively quantized the kik and snare, it sounded awful.
More detail needed. Describe "awful". Did you turn off the metronome for playback? There are some known bugs related to the metronome, so need to make sure that is not screwing it up now for you.
I then went and hand-moved the drum hits in the PRV. Of note here was the PRV was showing notes OFF the beat lines, even ones I quantized 100% and even ones I step-entered. Moving them even further away started getting some timing back.
Ok, that is weird and I'm confused. You're saying that when you quantized some music, the notes moved further away from the grid? Are you sure you were using simple normal quantization and not one of the groove or humanization variants? Just checking.
Thinking this was odd, I double-checked my piano part. Pretty tight to the grid.
I played everything else in by hand for 8 measures to test. It got a little loose after a while... meaning looser than what I know I played in.
I thought maybe it was too much MIDI, so I bounced everything down. Sounds kind of choppy.
Still don't have a solution. I was just going to re-sequence and try keeping everything as tight to the grid as possible and bouncing down to see if PDC might have something to do with it.
That does not sound alright and frankly to me sounds like bugs in Cakewalk, but in order to help them figure it out we need to figure out how to replicate the problem consistently and try to isolate exactly what the problem is. You have done a lot of different things in your description, I guess desperately just trying to get it to sound good. Can we try a couple tests, one by one and isolated? First, I want to know if you enter some notes manually into the PRV and make sure they are quantized to the grid lines...when you play it back through a VSTi, does it sound tight? And before you do that, make sure you address the known metronome bug(search this forum for info about that, fix that first)
|
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/10 22:47:09
(permalink)
Thanks Jim, for the well thought out post. I am certainly not a computer engineer nor did I ever have a much desire to be one. Just an old musican that does not know much of anything about the true whys or wherefores re this topic. Only my experience with it.
When I signed up with the Cakewalk forum coming up on 4 years ago, the issues that are now being discussed full tilt in this thread where painfully obvious to me. I have long sought after answers and continued upgrading in the hope the problem would be solved. But here we are now at version 7 (I'm still at 6 though) and on it goes.
Somewhere, there is a post by one of the bakers that mentioned some type of timing problem that had crept in and would take a long time to solve. I believe this was around version 3 or 4. I will have to look see if I can find it.
Here in a nutshell is why I just can't fathom how detectable midi errors can be a issue with the computing power that is available to skilled programers now. I'm talking midi only.
I also realize this is Cakewalks forum.
1: Several have already stated their satisfaction with OLD Roland hardware sequencers. No timing issues at all that I ever found. A google search will prove it too. We're talking 20 years ago now. And what does that thing have in it, maybe 48k memory, if that ?
2: I watch my ancient Timeline Microlynx take the MTC that Sonar spits out (and who knows if that stream is steady or not), convert that into smpte 29.97nd and absolutely without error resolve and LOCK the 16 track and the digtal DTRS machines to frame accuracy. It show's you that it's locked and it stays locked no matter what Sonar does. I can't even comprehend the math involved in keeping all that stuff resolved.
3: I'm running a dual core machine, disk drives that set basically stopped with almost nothing to do, enough memory to get a rocketship to mars and beyond, and with only a couple of audio tracks running. And yet midi timing all over the place.
I would hope that if midi events just can't be reliably handled on a pc running windows, someone would put a honest disclaimer on the package stating as much. It just should not be pot luck at this stage. Heaven knows we're talking about serious money being involved once folks have invested in high end sample libraries, interfaces, hardware instruments and everything else desired or required to set up a decent project studio and to then (afaic) be continually discouraged that the foundation of their investment is inhibiting creativity and find themselves spending most of their available time trying to figure out what the problem is.
Personally, I have wanted this topic to be brought out of the closet for a long time and I had just about given up on others caring about it. I hope the thread doesn't get all weird now.
Regards,
Danny
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
|
...wicked
Max Output Level: -1.5 dBFS
- Total Posts : 7360
- Joined: 2003/12/18 01:00:56
- Location: Seattle
- Status: offline
RE: MIDI "Jitter" - It Does Exist
2007/10/11 00:07:43
(permalink)
ORIGINAL: dewdman42
And before you do that, make sure you address the known metronome bug(search this forum for info about that, fix that first)
Will do. I'll report back with more info when I accomplish said tasks. thanks!
=========== The Fog People =========== Intel i7-4790 16GB RAM ASUS Z97 Roland OctaCapture Win10/64 SONAR Platinum 64-bit billions VSTs, some of which work
|
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/11 00:45:08
(permalink)
A couple of interesting points to note:
Two people (unless there's another post that I missed) alluded to the concept of sync'ing the audio and MIDI streams, and the fact that this requires a great deal of computation by the host computer, whether it's at a software or OS level. However, I'm not sure this is entirely relevant to the MIDI jitter discussion. Think about slaving a hardware sequencer to a 2" reel-to-reel 24-track tape machine using SMPTE, MTC, or whatever other sync box you want to use. Based on tape stretching and pulling, motor fluctuations, etc., there may be some subtle "drift" or tempo-skewing, but the hardware sequencer's MIDI events will still retain their proportional timing relationship to each other, even if the tempo drifts in and out. For that matter, even if the tape itself has some drift, it doesn't wreck the groove or timing of the audio recorded on it, because the proportional timing relationship of the events on that tape is preserved.
Now take, as a comparison, the MIDI jitter situation. The problem is that with MIDI jitter issues, the timing relationships between the MIDI events themselves is lost. This is what makes a performance sound less "tight" on playback than it did on recording. And it's not a MIDI / Audio sync issue. Perhaps there could be a MIDI / Audio sync solution to the problem, whereby the MIDI timestamping can be dependent on the audio clock instead of the system clock, but the MIDI jitter problem itself does not derive from an audio sync issue, as far as I can tell.
And I, too, am *extremely* pleased that significant numbers of other people are finally taking an interest in this.
|
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/11 00:58:52
(permalink)
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.
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.
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.
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.
|
Nick P
Max Output Level: -44 dBFS
- Total Posts : 3112
- Joined: 2006/09/01 18:08:09
- Location: Area code 392 - Arlington Hts, IL
- Status: offline
RE: MIDI "Jitter" - It Does Exist
2007/10/11 05:59:19
(permalink)
dewdman42, pianodano, Jim Wright, RTGraham, et al...., this is SO GREAT! I can't wait to have the time (couple of days) to go through every piece of information contained in this thread. I will also be forwarding it to Cakewalk. What an amazing resource. Mucho thanks. Let's keep going!
Cakewalk Forums - A Great Learning Resource For All Things Cakewalk!
|
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/11 17:53:44
(permalink)
ORIGINAL: RTGraham
A couple of interesting points to note:
Two people (unless there's another post that I missed) alluded to the concept of sync'ing the audio and MIDI streams, and the fact that this requires a great deal of computation by the host computer, whether it's at a software or OS level. However, I'm not sure this is entirely relevant to the MIDI jitter discussion. Think about slaving a hardware sequencer to a 2" reel-to-reel 24-track tape machine using SMPTE, MTC, or whatever other sync box you want to use. Based on tape stretching and pulling, motor fluctuations, etc., there may be some subtle "drift" or tempo-skewing, but the hardware sequencer's MIDI events will still retain their proportional timing relationship to each other, even if the tempo drifts in and out. For that matter, even if the tape itself has some drift, it doesn't wreck the groove or timing of the audio recorded on it, because the proportional timing relationship of the events on that tape is preserved.
Absolutely correct. Issues related to syncing audio and MIDI streams are different from the issues that lead to MIDI Jitter. Audio/MIDI sync issues have to do with synchronizing two or more independent "clocks". MIDI jitter issues have to do with the fact that MIDI messages, as handled by Windows, have "flaky" timestamps.
Now take, as a comparison, the MIDI jitter situation. The problem is that with MIDI jitter issues, the timing relationships between the MIDI events themselves is lost. This is what makes a performance sound less "tight" on playback than it did on recording. And it's not a MIDI / Audio sync issue. Perhaps there could be a MIDI / Audio sync solution to the problem, whereby the MIDI timestamping can be dependent on the audio clock instead of the system clock, but the MIDI jitter problem itself does not derive from an audio sync issue, as far as I can tell.
Yes. I call this the "flaky Windows timestamp" problem. Why flaky? The timestamp is referenced to an internal Windows clock (system clock or something else) -- that may not keep time very well. Individual clock interrupts can be delayed due to higher-priority CPU work -- like streaming audio. The timer rate may be 1000 interrupts per second, but that does not mean a new interrupt occurs at the start of each millisecond. Clock interrupts can be skipped for, say, 3 milliseconds, and then come in a burst (3 interrupts in the same millisecond) to make up for it. You can see how this can introduce jitter (and also why lower PPQN values, which quantize the MIDI to something like 5 millisecond boundaries, can compensate for this somewhat). Another issue - is that the low-level MIDI event scheduler doesn't fire MIDI messages out of the hardware port directly, it just sends MIDI events to the driver for the port. For something like USB, the event has to travel through the USB driver stack ... which can take a while .... and may then have to wait until the next USB frame is ready to go out the USB port. (With USB 1.1, frames are sent once per millisecond - which adds 0.5 milliseconds of jitter right there. With USB 2, microframes can be sent more often (8x more often?), so USB 2 can potentially support lower-jitter MIDI I/O). Of course, Firewire drivers also need to queue up data, assemble packets, fire them down the wire -- this all takes time as well. A direct PCI-based interface (say, on an EMU 1820M or 1616M) has a lot less overhead involved with getting events from the low-level MIDI event scheduler to the actual hardware MIDI DIN port. So -- less jitter, less lag, happier musicians (other things being equal, and unless the drummer is hitting on your girlfriend/boyfriend, of course). All of the above affects incoming MIDI too, but in the reverse direction. A lot can happen between the point when an incoming MIDI event is processed by the MIDI port hardware, and the point at which the event is timestamped by the MIDI driver (or low-level sequencer engine, as may be). 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
|