Here's an interesting article from Craig Anderton. Note in particular the section in the middle about PPQ

http://www.harmony-central.com/articles/tips/midi_revisited/

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...

"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

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?

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.

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

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?

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.

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

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.