ORIGINAL: pianodano

Dewdman42,

If it counts for anything at all, I'll give you an A+ for tenacity.

Carry on.

+1. I can't wait to find the time to print and study this whole thread. It's like a massive lesson in MIDI timing. Maybe a candidate for a sticky

ORIGINAL: dewdman42

Regardless of whether you quantize or not, the notes all must land on the red 960 ticks. If you want the note on tick 121, because you used less than 100% of quantization..that is fine..it would not be exactly on a 32nd note boundary. But where it ends up being will not be in a metrically balanced location at finer level of meter detail.

I don't think I can explain this concept any better than I have already tried. If people still aren't getting it, then I give up. Do you get it? If you want the note to be slightly behind the beat by one tick, it can be one or two 960 ticks, which have no musical relevance whatsoever, or it can be a 768 or 1536 tick which would place the note in a location that has metrical balance in the sub-millisecond range. I'm not sold that its irrelevant that deep down.

capturing the fine nuance of a midi realtime performance is fundamentally flawed because of all the reasons we have discussed, but again, do you care if the notes end up on metrically balanced ticks or scattered non-musical random ones? You aren't controlling their exact location by your playing, the 960 grid is.

Just when I thought this thread had finally flown mathematically over my head, it all clicked.

That said, I do understand what you're getting at, dewdman, and I think that its musical relevance is actually quite subjective, and dependent upon the individual performer. I think that there are probably some performers for whom there *is* an internal clock that continues to subdivide beyond the "usual" note values (i.e. into 256ths, 512ths, and tuplets thereof, etc.), and for those people perhaps the subtle timing adjustments in their performances are related to the "musical" subdivisions that you describe (i.e. those that would be more achievable on a grid of 768ppqn, 1536ppqn, etc.). I think that there are probably also performers for whom subtle timing shifts in their performances are more "absolute," and don't necessarily depend upon the availability of "musical" ticks on which to land. So whether or not your observation "makes a difference" would depend on what type of performer is using the software. In theory, that is.

Yea RT, I tend to agree. Now if we could just get rid of the midi slop. The slop pretty much makes it impossible for anyone to perform their midi parts and get them within 1ms of where they intended. The slop is going to have an effect and then the quantizing effect of 960 is going to have an effect and basically what you end up with is just plain slop if you care about what happens within a millisecond or two.

It's times like these that I wish I understood quantum physics.

dewdman - you seem a little hostile towards me, as if I haven't been trying to debate this logically in a non-disagreeable sort of way. It doesn't bother me at all if there turned out to be any truth in your theory, and I encourage you to find a way to test it and present the results. All I'm saying is that I don't know in the end which one would really sound "better", "tighter", "more accurate", all of which may actually be difffert things in this case. I'd like to know, in the same way as I found it a good learning tidbit that everything is really at 960 anyway, so it's just for show.

For what it's worth...

Hate to beat a dead horse, if it's really dead, but I just found this article by Craig Anderton on Harmony Central and it seems to answer a lot of these issues. He claims that the only time (no pun intended) that MIDI timing is an issue is when dealing with outboard MIDI synths. He feels that using softsynths allows for really tight timing. Here's a link to the article:

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

I just found this article by Craig Anderton on Harmony Central and it seems to answer a lot of these issues.

I like Craig Anderton's writing, and agree with him on many of these issues, but he makes the same mistake of assuming that when you set Sonar to a lower PPQ, that it actually stores things at that resolution, thus taking some load of the CPU. But as we now know, this is not the case. This might be true of some other sequencers, but not of Sonar, which is the example he used in the article. I might have to drop him a line and set him staight. .

Yep. I actually mentioned this article a while back right here on this thread : http://forum.cakewalk.com/fb.asp?m=1182551

It would be very interesting to hear his feedback after reading this whole thread.

brundlefly - I got similar results as you using a Lynx One interface. I played a steady beat out and recorded back into sonar on another track. I also got a max deviation between events of about 2.5-3ms. What was interesting to me was there was a pattern to the deviations so the talk previously about interrupts and how they can be skipped a and come in bursts seems relavent. Perhaps windows is doing various tasks and skips interrupt calls on a regular basis so that you get patterns of deviation as the system tries to make up the difference in order to keep a certain resolution.

For what its worth using the same test above I got almost perfect results using an Amiga with a resolution of about .89ms per tick. There was virtually no variation in the recorded note timing. Way better than Sonar. I think Sonar is probably as good as it gets on windows but Amiga and Atari definitely will be much better. From my tests Amiga seems to have the edge. It also has more hardware timers than the Atari so maybe that is why.

Jon

I'm getting excellent results with Delta1010LT, using MME and timestamping:

 ================ Results Per Message =====================================
 
 MESSAGES		   Snd		   Rcv		    Snd+Rcv
 
 Message TotalTime:	 1235.90 ms	 1237.72 ms	 2473.63 ms
 Message MaximumTime:	    0.16 ms	    0.43 ms	    0.46 ms
 Message MinimumTime:	    0.02 ms	    0.00 ms	    0.02 ms
 Message AverageTime:	    0.04 ms	    0.04 ms	    0.08 ms
 SysexTime:		 2896.59 ms	-2856.36 ms	   40.24 ms
 SysexAverage:		    0.29 ms	   -0.29 ms	    0.00 ms
 
     <   1 ms:		   31250	   31250	   31250
   1 -   2 ms:		       0	       0	       0
   2 -   3 ms:		       0	       0	       0
   3 -   4 ms:		       0	       0	       0
   4 -   5 ms:		       0	       0	       0
   5 -  10 ms:		       0	       0	       0
  10 -  20 ms:		       0	       0	       0
  20 -  50 ms:		       0	       0	       0
  50 - 100 ms:		       0	       0	       0
     > 100 ms:		       0	       0	       0
 
 Message count:		   31250	Sysex count:	     324
 Sysex size:		    9999	Sysex passed:	    9999
 
 Message latency:	    0.08 ms	Total time:	  64.617 sec
 Message jitter:		    0.08 ms
 Message max deviation:	    0.38 ms
 
 
 
 ================ Results Per Byte ========================================
 
 BYTES
 
 Byte TotalTime:		 1115.34 ms
 Byte MaximumTime:	    0.40 ms
 Byte MinimumTime:	    0.01 ms
 Byte AverageTime:	    0.04 ms
 
     <   1 ms:		   31250
   1 -   2 ms:		       0
   2 -   3 ms:		       0
   3 -   4 ms:		       0
   4 -   5 ms:		       0
   5 -  10 ms:		       0
  10 -  20 ms:		       0
  20 -  50 ms:		       0
  50 - 100 ms:		       0
     > 100 ms:		       0
 
 Byte count:		   78093
 
 Byte latency:		    0.04 ms
 Byte jitter:		    0.04 ms
 Byte max deviation:	    0.37 ms