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.

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

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/

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.

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
 
 

ORIGINAL: brundlefly

What generated these data? .08ms average round trip? I don't think so.

Believe it or not, these numbers are very consistent, very repeatable, and very real.

http://earthvegaconnection.com/evc/products/miditest/index.html This is the test program

Settings were: MME with timestamping, max sysex of 60

Would anyone else with a M-Audio PCI card care to confirm these numbers?

Ran a quick test of my 1820m's MIDI ports, and got results more like what I would expect in the real world:

Snd+Rcv times from 4.76ms to 6.26ms with an average of 5.71ms. This is about twice what I get when I just do a loopback test with Sonar, which gives me a round trip of about 2.6ms. Turning off timestamps took the reported average up to 6.75ms with a high of 15.54ms! But it still says the Snd times are averaging .01ms, and attributes all the latency to the Rcv time, which doesn't really make sense.

strungdown, that is true, but Sonar does not record those absolute times. It rounds to the nearest 960ppqn.

If a MIDI message is 3 bytes and the midi data rate is 31.25Kb/sec, thats 0.000 256 seconds per byte, or 0.000 768 seconds per (3-byte) message minimum.

Right. About 0.8ms, not 0.08 as reported for the round trip in your test results.

Incidentally, a couple of notes on my test results: First, I was not able to use MME; it's not supported my the 1820m's driver. I had to use DirectSound, and I had to turn off SysEx massages, as there seemed to be a problem with them. I need to check into this some more, as I use SysEX all the time to control my outboard synths with Sonar, and have no trouble with it. Also, I found that running the test with just 100 messages, rather then the default of 31250, produced completely repeatable results in much less time.

I had the same trouble with the SysEx. For some reason that seems to screw up a lot of devices.

I had the same trouble with the SysEx. For some reason that seems to screw up a lot of devices.

Yeah, I can't get SysEx to work. Found another fun thing to do, though... Put a hardware synth in the loop, using the Thru port to return the data, and enjoy the random bleeps and blips it produces! Didn't affect the latency at all, using my Alesis QS8.

not sure about this - i had no miditiming problems with my atari st 1040 nor with my 486dx with 40 mhz :-)
its mostly a driver problem and i believe that some newer sequencer versions dont take classical midi processing up to the rest...there are so many new functions and apps that probably midi is sort of handeled alongside....
maybe the guy starting the thread uses 3 8 channel interfaces with all channels playing and some mid through also...then i would technically understand the inherent delays..but otherwise....

cheers

AtariST had really good realtime midi handling built into the OS. Your old 486 was probably running DOS or 16bit windows. Those OS's also had ways to force tighter midi timing through clever coding. Later versions of Windows became true multitasking operating systems, which removed the ability for a software maker to force midi events to be handled as tightly.

This is just the way things are. The realtime handling of external midi is something that a modern OS will balk at unless it has special RealTime features built into it like the AtariST did. Everything happens in buffers now. The only way we might in the future get truly tight and accurate midi will be when someone comes up with a standardized way to timestamp the midi events as close as possible to the source as possible, and have those timestamps be syncronized to a master sample accurate clock. As far as I know, the only way you do that today is using MOTU hardware in conjunction with Digital Performer. It is not a standard. The realtime latencies would still be there though. The only thing is that at least the actual timestamp would be created as close as possible to when the actual key is pressed on the midi keyboard, etc.. and if everyone in the chain respects that timestamp, then it would end up in the track exactly where it was played. But while playing through a soft synth, there would still be the realtime delay causes by the midi interface, the driver and audio buffer latency.

That's just how it is... The only way around this today is to use something like a Fantom that has a sequencer in it. The keyboard and sequencer and soundsource are all in the same machine...and hopefully...not going through the midi bottleneck. So you can lay your tracks down with that, then transfer the midi to your DAW for tweaking later.

Interesting. One thing about DirectMusic, ironically is it's less direct than MME, as it goes through an additional layer: the DirectMusic.dll. Every version of the DirectMusic DLL has a "featuer" where it screws up the ordering of SysEx messages. Some people think this is because DirectMusic was designed for games and never tested with MIDI.

If I turn off timestamping, I get something on the order of 1-2ms latency and I think somewhere 2ms or less jitter but i don't have the exact numbers yet (will run it again later).

Interesting. I guess the 1010's MIDI ports are right on the PCI card? My 1820m's ports are on the dock, which probably slows things down a little. But I don't understand why my MIDI loopback test yields a round-trip of only 2.6ms, while the Tester says 5.7ms. I'd be curious what results you get from a basic MIDI loopback test, using Sonar. If the tester is right, you should have re-recorded MIDI events come in no more than 2 ticks behind the source MIDI at 125BPM (.5ms/tick at 960PPQ). That would be pretty impressive.