ORIGINAL: dewdman42

For anyone interested, I set out to emulate the timing behavior of a 96ppqn hardware sequencer here:

http://forum.cakewalk.com/fb.asp?m=1191696

Some interesting results, in light of the fact that Sonar is using a hardwired internal midi resolution of 960ppqn.

Cool, dewdman42. Thanks!

For anyone interested, I set out to emulate the timing behavior of a 96ppqn hardware sequencer here:

http://forum.cakewalk.com/fb.asp?m=1191696

Some interesting results, in light of the fact that Sonar is using a hardwired internal midi resolution of 960ppqn.

Interesting idea, using input quantize to emulate lower PPQ recording, but the result is the same as quantizing to that lower resolution after the fact, right?

Exactly the same as quantizing after the fact, perhaps just a bit more convenient. The only real advantage I think to input quantize is that if you are doing loop record, the material will be quantized when it comes back around in the loop to play back what you had laid down in previous pass, it will already be quantized. In this example, it would be pseudo quantized to 96ppqn.

ORIGINAL: dewdman42

For anyone interested, I set out to emulate the timing behavior of a 96ppqn hardware sequencer here:

http://forum.cakewalk.com/fb.asp?m=1191696

Some interesting results, in light of the fact that Sonar is using a hardwired internal midi resolution of 960ppqn.

Interesting... having skimmed the thread, I wonder to what extent incoming DIN and USB jitter might still place a note on the "wrong" tick. Or maybe not.

Yea..definitely in terms of recording from a keyboard, the incoming jitter is going to round everything to the nearest tick from an unsynchronized millisecond timer, USB slop, DIN slop, etc. The "slop" is going to be there and there is not much we can do about it.

However, the question is, will it round it to a tick that lands on a metrically even point in time based on 3/4, 4/4 or will it land on a point in time that is completely out of sync with the meter, or rather has no musically metrical timebase? This rounding that has to take place, is kind of like a very fine level of quantizing. Not just kind of. It is! The thing is, at certain PPQN's, like 960 for example, the divisions for that quantizing are not metrically musical at 3/4, 4/4. Get it?

I have created an interesting spreadsheet related to PPQN's in Sonar, for a while it will be available at the following link:

http://public.dewdman42.fastmail.fm/ppqn_map.xls

Quick explanation. Blue is good. Yellow is bad. Bad meaning that the PPQN grid becomes un-musically-metrical at some point. Boldface lines are the PPQN's provided by Sonar. The rows with red indicate PPQN's which OUGHT to be provided. Across the top I also added some reference times in milliseconds based upon a tempo of 120bpm.

Note also that nearly all of this is hypothetical since currently Sonar stores everything internally at 960ppqn. But also notice that 960 is not even close to being the best one for 3/4, 4/4 type music. With the current limitation of hardwired 960, you can emulate lower resolutions with quantizing, but there are really only a handful of resolutions you can emulate that way. I reckon 192 is the best option, related to this discussion, for metrically sound divisions down to the finest level of detail:

 quant     emulated
 ticks     PPQN
 ------    ------------
 10         96
 5         192
 4         240
 3         320
 2         480
 

dewdman42 - thanks for the great resources and input you've provided throughout this thread.

Thanks. This is a subject that has been irking me for a long time. The spreadsheet I did was very interesting I thought.

In light of it, I find myself fundamentally wishing to record all of my midi tracks at 768ppqn. Its very unfortunate to me, in my mind that Sonar does not provide this resolution, which in my mind is the like the golden resolution for anything under 960. 1536ppqn would be even better, but I doubt we'll ever see that. To me, 1536ppqn would be the ultimate golden resolution for recording typical 3/4. 4/4, 6/8 midi tracks.

But the fact that Sonar is hardwired to store and quantize midi events to a 960ppqn grid is very disappointing to me. I hope they will consider improvement in this area.

I think with the midi slop we've been talking about, some of the imprecision we're talking about is blurred by that when recording live midi tracks. And really, at 960ppqn, we're talking about inaccuracies that are under mostly less than 0.5ms. But the big thing to me is that the 960ppqn grid pushes many events to non-musically metrical points in time much of the time. There is something in the back of my head screaming out loud that this may be contributing to a sense of looseness that people seem to have. Or I could just be asking for too much. Dunno. Nevertheless, there we are.

Anyone know if any other sequencers also enforce an internal hardwired 960 grid for recording, quantizing and editing midi data? Or do people know if other sequencers handle things in another, perhaps better, way? What about some plugins which have their own internal sequencers, such as Guru, EZD and other rythmn oriented plugins?

I'm very curious what happens if you run FruityLoops inside Sonar, or Ext or one of the other plugin sequencers out there...and wondering what kind of midi resolution they provide..perhaps providing one of the more musical resolutions.

But the big thing to me is that the 960ppqn grid pushes many events to non-musically metrical points in time much of the time.

I'm having trouble seeing what the big concern is in real terms, given that 960PPQ gives you precise whole-number intervals and durations down to a 256th triplet, leaving only resolutions of less than 10 ticks (5.2ms at 120BPM) getting "quantized" to "non-musical" values. I seriously doubt that there are a significant number of musicians working in MIDI that have the performance control and consistency to make this a concern. I know for certain it's not a problem for me. I don't think I've ever had a need for quantization values below a 32nd triplet, which accommodates quantizing mixed 16ths and 16th triplets, and won't do too much damage to a grace note, most of the time.

One of the advantages of 960PPQ to me is that all the usual values end in 0, so it is easy to see what intervals were intended when looking at notes in an event list, and how far off the mark they are, so you can choose an appropriate quantizing value and percentage to tighten things up without stomping too hard on anything. This becomes significantly less intuitive at 384 or 768 PPQ. As an example, all the testing I just did in connection with this thread would have been made much more painful, trying to quickly record how far each event was from its target. As it was with errors mostly in the single digits, I could pretty much just read the last digit of the tick value, and that was the error. Imagine trying to do that with target values ending in any of 8, 6, 4, 2 or 0. No thanks.

I still think that the people who are hearing or feeling something being significantly "off" from what the played are experiencing some sort of system-specific problem that is bigger than a tick of jitter, or a fraction of a tick of quantizing.

Well you could be right. Or not. We can only speculate without having a system to try it on, or if someone knows about any scientific studies that might reveal something related to the human perception of metrical divisions at such a fine level of detail. Otherwise, we're only speculating either way. In any case, there is not much we can do about it. So I digress. I just thought it interesting and wish I had a way to try out true 768. Seems like I should have the option and it seems like the midi resolution setting in Sonar should mean something.

Seems like I should have the option and it seems like the midi resolution setting in Sonar should mean something.

I'm with you there. More options are always good, and they definitely fooled us all with the "placebo" clock setting dialogue.