Was it Bohr that said "Anyone who thinks they understand quantum physics clearly doesnt understand quantum physics"?

ORIGINAL: RTGraham

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

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.

ORIGINAL: brundlefly

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.

Hehe

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

I agree...something funny seems to be going on. I'm going to do some more testing tonight and get to the bottom of this

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

1000 bpm - do yo want me to fall asleep - get lost with your downbeat elevator music :-)

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.

I agree...something funny seems to be going on. I'm going to do some more testing tonight and get to the bottom of this

I tested my MOTU MIDI Express XT USB which supports MME, and got an average of about 6.9ms. Then I retested the 1820m, and found that the test would now run in MME mode (?), but always reported the low .10ms average, whereas in DirectMusic mode, it was still consistently at 5.71ms as before. At first I speculated that the test app might be getting confused about which returned message goes with which sent message, matching up outbound message 2 with inbound message 1, and getting this ridiculously low value. I set it to send only a single test message to eliminate this possibility, but it still came up with values from .03 to .3ms for the one message. And finally, I found that SysEx worked in MME mode with the 1820m, but would actually return negative values, and would not work with the Express XT at all.

I'm not sure what's going on, but I think this applet has problems in MME mode with some hardware/drivers. And I don't think the sub-millisecond values are real.

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

Here are my numbers.

MME; NO timestamping:
latency 0.88ms
jitter 0.22ms
max deviation 0.53ms

MME; with timestamping:
latency 0.09ms
jitter 0.08ms
deviation: 0.24ms

DirectMusic, NO timestamping:
latency 0.96ms
jitter 0.21ms
max deviation 0.60ms

DirectMusic, with timestamping:
latency 0.35ms
jitter 0.03ms
max deviation 0.49ms

KernelStreaming, NO timestamping:
latency 0.92ms
jitter 0.15ms
max deviation 0.44ms

KernelStreaming, with timestamping
latency 1537229.00 ms (??? total time was 0.206 sec)
jitter -1.#J ms (???)
max deviation 0.02ms

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.