I had to reload my Roland JUNO DS-88 drivers, and noticed some latency when running the Juno through a VI channel (since my Steinberg UR28M interface is set to 2048 samples, 51/55 msec I/O),
I ran the Plonk test (record the audio of the mic hearing the key go “Plonk” when you strike it hard while also recording the MIDI input), zoom way in and measure the time difference of the onset of the two recorded events).
Running through a VI Channel:
MIDI is 4 msec earlier than audio
Running through a MIDI Channel:
MIDI is 2.8 msec earlier on one test, 3 msec later on another
Now I’m not unhappy with how recording is going (I have direct monitoring on, and I don’t notice recorded events being out of time), but I’m wondering about those results.
Can anyone address them knowledgably please?
Thank you!
PS: In Cubase Preferences I have UNchecked: “ASIO Latency Compensation Active by Default”, and “Add Latency to MIDI-Thru Processing”.
PPS: I reviewed the last “Plonk Test” forum topic I could find, c.2012 (!) before posting.
Did you do an audio loopback test first so you know your audio is being placed correctly?
Why did you disable those options? How are results with them enabled?
Are you using MIDI over USB or via the good ol’ DIN-5 cable?
A simple “Note ON” message over the DIN5 will need about 1 msec just to travel the cable at 31 kbauds. A 5-note chord will take 5 msec minimum if nothing else is happening on the MIDI bus (pedal, aftertouch, Note offs, clock, etc. etc.)
Over USB, it’s over 10 000 times faster…
Plonk test gone mad: use a high-speed camera to measure the delay between the key going down and the MIDI activity blinker in your DAW… getting further away from making music now…
That’s only if “running status” is not implemented.
People who are more knowledgeable than I am on the subject have explained that this isn’t necessarily the case. Apparently MIDI over USB can get throttled down to 31,250 bits/second. For compatibility reasons if I don’t misremember.
Those options are disabled by default, or at least I didn’t disable them.
The rest of all this is a little bit over my head. I was just looking to see how “non- simultaneous” singing with keyboard playing would be, and it looked pretty close, less than 5 msec.
I think I was expecting something in the neighborhood of the audio card’s latency.
About “running status”
You’re right it saves a byte when playing multiple notes without any interruption by a clock message or any other message (the slightest pedal move for ex.).
About throttling
It has to (sort of) throttle down only if there is a legacy MIDI port in the thru chain (for obvious reasons).
However, a well written USB-MIDI driver will not throttle when sending messages from a kbrd to a host/DAW. (no reason to fear buffer overflows)
Sadly USB-MIDI protocol does not include any ack/nack or flow handshaking, but common design practices can overcome that easily.
I didn’t say there was. I merely wanted to provide context.
I’m curious about this statement. From my experience, a MIDI over USB device typically do not expose MIDI Through functionality and I don’t see a practical reason for it either.
The way I interpret Pete’s quote above is that speed reduction can occur due to a number of factors. But I would have to leave it to them to clarify.
Another thing that is not immediately clear to me either is if the constrained speed of 31,250 bits/s is with 32bit USB packets or 10 bit MIDI messages. I’m assuming that latter since otherwise MIDI over USB would have a significantly lower bandwidth compared to MIDI over 5-pin DIN.
For example: Our USB MIDI 1.0 Class Driver in Windows does not do any speed throttling. However, most MIDI 1.0 devices do not operate meaningfully faster than the MIDI 1.0 DIN spec speed. It may be due to their UART implementation, or for compatibility with the MIDI 1.0 DIN ports they almost all have, etc. It’s going to be a device-by-device case.
The other place where you run into MIDI 1.0 message delays (often characterized as jitter, but that’s not 100% correct) is with multiple channels on the same cable. Everything is serial, so 16 channels have to occupy the same stream, and can cause note on/off messages to take longer than expected.
But what Y-D said about the speed of a 5-note chord is 100% correct. Throw some channel pressure/aftertouch in there, or some pitch bend, and you are looking at much longer delays.
And if devices have MIDI Thru connections, depending on how that is implemented, you can see additional delays. The classic electrical version of that is fast enough. But soft-thru (goes through a microcontroller first) tends tendstends to have more delay. But, again, very implementation-specific.
For USB MIDI reliability on Windows, if you are really trying to optimize it (not normally necessary, but can be done), you need to try to isolate the USB connection. That requires knowing how the USB ports are wired up internally, and then keep your MIDI stuff separate from, say, audio, or your mouse, or other things that will be sending/receiving data at the same time.
On a laptop, this usually isn’t an option, but on a desktop you often have multiple USB controllers available to you. But, again, this is a bit of hyperoptimization that is not normally needed.
getting further away from making music now…