ORIGINAL: Steve_Karl

Yes. I totally agree.
More ticks = less quantization = more resolution = more accuracy.

You missed the point I was making initially and that most of this thread is about. More resolution only equals more accuracy if it is stable. Windows-based sequencers are not stable to that precision while receiving midi input from an external midi controller, therefore it is not "accurate".

Higher PPQN really = more "theoretical precision".

But if its going to jitter around by 2ms in either direction, then you have several ms of slop, which is a lot closer to 96ppqn resolution than most people seem to want to believe. The truth is that your computer can keep up with things and do a better job of actually being stable if you use a lower PPQN. That is the point I was trying to make. If you actually think you need 480 or 960 theoretical precision, then by all means use it! However, realize, that in terms of capturing your real time performance through a midi interface, it is not doing so "accurately". There are several ms of midi slop. if you're playing back through an external midi device it is also not doing so accurately, you can figure the same slop. The point is that higher PPQN settings could make things "sloppier" in that regard, but with yes, higher theoretical precision. That is not even close to being accurate as you envision.

All that being said, once you have the performance captured in the sequencer, if you plan to play it through soft instruments, raising the PPQN to higher values can be useful because then you can nudge notes around using the higher precision and so long as there aren't any bugs in the plugin, the audio render will be accurate to that higher PPQN value, so in that case, it makes sense. But the higher PPQN values can impose more work on any hardware midi interface work that needs to happen, and frankly are nothing but fantasy about how you capture the performance.

Don't confuse the term acuracy with lining up exactly on the bar lines.
Accuracy by my definition here means "true to the actual human performance."

Definitely. Also consider that at 96PPQN, the quantization you are talking about is something like 256th note triplets. The truth is that most people don't need more theoretical precision than that. In fact I would go so far as to say that the implicit quantization to that level is helping them, not hurting them in terms of playing in a groove, in the pocket, behind the pocket, etc.. all of it....

Where the higher precision becomes desirable is for things like glissandos, clusters, grace notes and other subtle nuances that truely need finer resolution to capture exactly the right way. However, the current WindowsOS simply does not capture that way consistently. You might get lucky, you might not. You really can't count on 480 or 960 PPQN to be captured anywhere close to accurately. Personally, I have my PPQN set to 384 or sometimes even 192.

Steve, Its pretty obvious to me you didn't read the whole thread, you responded to one of the first posts I made. I suggest you read the whole thread, there is a lot of useful information here and I just repeated some of it.

I think this has been a great thread, but we're just going in circles now.

Moral of the story, lower PPQ values will give you more reliable and error free, reproducible playback. It will play back more exactly what you see on your PRV.

I was curious about this concept, given my earlier reported finding that Sonar is apparently storing event times at a resolution of at least 960PPQ (and probably actually at the project's sample-rate resolution - 44100kHz in my case), because you don't lose the resolution displayed in the event list when you go back and forth between higher and lower PPQ.

So I did another test. I created a 4-bar clip containing a series of 15-tick long MIDI notes step-entered at 16th note intervals (240 ticks at 960PPQ), such that the last note event was at 4:04:720. I then used Fit-to-time, to stretch the clip so that the last event fell at 4:04:783 (63 ticks = later). This made every event interval exactly 241 ticks, so the 2nd event was 1 tick late, the 3rd was 2 ticks late, etc.

Still with me? Okay. I made a loopback recording of the events with MIDI resolution still set at 960PPQ. Then I changed the resolution to 48PPPQ and made another loopback recording.

Now, at 48PPQ, the nominal interval of a 16th is only 12 ticks, and a single tick is exactly 980 samples (at the "magic" 56.25 BPM as explained in an earlier post) vs. 49 for 1 tick at 960PPQ. So at 48PPQ, all my events should be quantized to 980-sample intervals, and only every 20th event should fall on the same sample as the corresponding event recorded at 960PPQ.

But this is not the case. I turned on AudioSnap on both tracks, and every transient in the 48PPQ track was within a few samples of - and frequently on the exact same sample as - the corresponding transient in the 960PPQ track. And, as intended, the interval was 241 ticks * 49 samples/tick = 11809 samples long plus or minus about 100 samples (two ticks at 960PPQ) which is about the level of jitter reported for TruePianos VSTi earlier.

So an indicated resolution of 48PPQ yielded an actual resolution equivalent to 960PPQ. It remains to be shown that this is true of events generated by en external sequencer, but I'll try to do that, and I fully expect to get the same result.

Another test I would need to do is to use a MIDI-only project, where the clock is "Internal", rather than "Audio".

So many questions, so little time...

That is interesting. It implies that if you initially create the note when in 960PPQN mode, then change the resolution to lower resolution, the note playback is NOT quantized, to 480PPQN during playback but basically retains the exact timestamp that was recorded at 960 precision. It means the value stated on the PRV at 480 is not correct any longer, at least the durations aren't per your test.

An interesting test would be to use 960 compared to say 96 to see if its more blatant. I think maybe if you add the note to the PRV while in 960, then change the resolution to 96, the internal timestamp is set to a value quantized to 960 and is not changed. But if you were to move or change the note while in 96 mode, then I bet the timestamp would become quantized to a 96PPQN grid.

But the real question is this...

if you have something you added to the PRV in 960 and then set the resolution to 96 and playback through an external midi device..what happens? Good luck measuring that. I would certainly HOPE that that notes would be sent to the midi interface at the lower resolution, but it sounds like there is some possibility they might not be.

It is my feeling that if you set the midi resolution to a lower value, then the internal timestamp should not be changed per say, but playback should be quantized to that lower resolution. This smells possibly to me like a design flaw in Sonar. If the PRV is not representing what is actually going to be played, its kind of a lie.

First: I did read the whole thread and I understand, conceptually, what your saying.

I can't argue with your theory because I'm not dealing with theory.
I'm dealing with my actual ~experience~, at the ears, as a musician.

In reality, my experience is that 960 ticks in Sonar is much more accurate to a human performance than 96 is,
An MC-500 Mark II would be intolerable for me in this stage of the work I do.

Jitter is a non-issue for me. I don't see it, I don't hear it. My rig is stable and the playback is reliably consistent.
I'm a happy camper at 960.
Now ... It's quite possible that the "slop" cause by jitter that you refer to is something I've gotten used to, and have learned to work with.
Kind of like the way we learn to work with the difference in the height of guitar strings, or the throw of a piano key.
Listen and adjust, and forget about it.

I work 99% of the time at 1.5 MS latency setting in Sonar and I can feel the difference under my fingers on my S90 when and if I have to move it to 2.9. I can adapt, of course, and everything is back to normal after a minute or 2.
5ms latency ( setting in Sonar ) is out of bounds and annoying to me. Things get to be noticeably difficult at anything over 2.9.

I make a point of keeping my tempos set high, as in, if the piece is really at 90 BPM, I'll intentionally run it at 180.
I usually don't worry about the tempo unless I'm getting down below 100 BPM.

My point is that everyone's "perceptions" are going to be relative.
If 96 is good for you then use it by all means.

Don't be offended If I don't see it the same way as you do.
It's just that I know what works for me from decades of experience.

But if you were to move or change the note while in 96 mode, then I bet the timestamp would become quantized to a 96PPQN grid.

I think this has to be right, because Sonar is only going to let you move MIDI events by whole ticks at whatever the current resolution is.

ORIGINAL: Steve_Karl
Jitter is a non-issue for me. I don't see it, I don't hear it. My rig is stable and the playback is reliably consistent.
I'm a happy camper at 960.
Now ... It's quite possible that the "slop" cause by jitter that you refer to is something I've gotten used to, and have learned to work with.
Kind of like the way we learn to work with the difference in the height of guitar strings, or the throw of a piano key.
Listen and adjust, and forget about it.

Yes, you have the slop, you just don't realize it. It doesn't matter how low you set your audio buffers. 1.5ms audio latency is great. However the slop we are talking about is not consistent latency...it is slop.

I make a point of keeping my tempos set high, as in, if the piece is really at 90 BPM, I'll intentionally run it at 180.
I usually don't worry about the tempo unless I'm getting down below 100 BPM.

This will not improve the slop factor, it will only make your computer work harder than it needs to.

My point is that everyone's "perceptions" are going to be relative.

Some perceptions are not based on reality.

ORIGINAL: dewdman42

ORIGINAL: Steve_Karl

Yes. I totally agree.
More ticks = less quantization = more resolution = more accuracy.

You missed the point I was making initially and that most of this thread is about.

I did read the whole thread. I just don't agree with your theory since my personal experience shows me that it works differently for me.

I don't mind that you "imply" that I'm imagining ( "fantasy" ) my experience, and I don't mind if you can't imagine that my experience is different than yours.
I also don't expect to convince you of anything or imply that your perceptions are not accurate.

It seems the best we can do is agree to disagree and suggest that everyone make up their own minds by listening to the results they get with different choices for PPQ.

ORIGINAL: dewdman42
Some perceptions are not based on reality.

Reality will always be relative to the perciever.

http://www.sightsea.com/music/singles/safety's_beginning.mp3

It is my feeling that if you set the midi resolution to a lower value, then the internal timestamp should not be changed per say, but playback should be quantized to that lower resolution. This smells possibly to me like a design flaw in Sonar. If the PRV is not representing what is actually going to be played, its kind of a lie.

Okay. I haven;t tried the external sequencer, yet, 'cause th eonly one I have runs at 48PPQ, so it would have to quantize the higher resolution file to store it.

But check this out:

I opened a new project, set it to 48PPQ, saved it and reopened it. I confirmed that the clock was set ti "Internal". I copied the 241-tick clip from the other file while it was still set at 48PPQ and displaying the 241-tick 16ths at 12-tick intervals, and pasted it into the new project. I changed the new project to 960PPQ, and the one-tick resolution was preserved in the new project.

I changed it back to 48PPQ, anyway, and did a loopback recording of the MIDI only, still running on the "Internal" clock setting...

At 48PPQ, the first 8 events "appeared" to have been recorded on exactly the same tick with no round-trip delay, and the 9th event was shown 1 tick late at 1:02:37, instead of 1:02:36. But when I changed to 960PPQ, the "truth" was revealed, All the events had varying latency of approximately 9-14 ticks (the same as found in earlier tests), and the event at 1:02:37, which you might expect would display as 1:02:740, was stamped 1:02:742

So it appears that no matter what you set for a PPQ resolution, Sonar is operating internally at least 960PPQ. And therefore it can display misleading values in the event list and PRV that do not accurately represent the timing with which they will actually be sent out.

Noel?