Topic by sigasa

  • Avatar
  • sigasa
  • Member
  • Offline
  • From: UK
  • Registered: 09-01-2008
  • Posts: 2,035

Topic: Use a high quality usb cable to get the best velocity response

Dear all

Just a note to say that I discovered a few minutes ago that the midi velocity signals via usb to host (usb) cable as compared with signals via my emu Xmidi midi to usb cable are very different in consistency. The usb to host method which only requires a usb cable is far more accurate than the midi to usb cable alternative. Not sure if it's the drivers or what???

I'm now going to purchase a high quality usb cable from gear for music in the UK.

My recommendation to anyone who has a to host usb option on their keyboard to use that rather than midi out.

Warmest regards,

Chris

Reply by groovy

  • Avatar
  • groovy
  • Member
  • Offline
  • Registered: 12-06-2009
  • Posts: 724

Re: Use a high quality usb cable to get the best velocity response

sigasa wrote:

... velocity response ...

Did you mean latency? - The MIDI velocity is not changed by the transport medium.

Reply by sigasa

  • Avatar
  • sigasa
  • Member
  • Offline
  • From: UK
  • Registered: 09-01-2008
  • Posts: 2,035

Re: Use a high quality usb cable to get the best velocity response

groovy wrote:
sigasa wrote:

... velocity response ...

Did you mean latency? - The MIDI velocity is not changed by the transport medium.

Sorry, I meant the accuracy of the midi output i.e. nothing to do with curves etc.

Reply by groovy

  • Avatar
  • groovy
  • Member
  • Offline
  • Registered: 12-06-2009
  • Posts: 724

Re: Use a high quality usb cable to get the best velocity response

To get an idea of the "MIDI-accuracy" I made an experiment with two different chains.

Chain A: DigitalPiano connected via USBtoUSB with my Pianoteq-Laptop. (my standard setup)
Chain B: DigitalPiano connected via a Miditech DINtoUSB converter with my Pianoteq-Laptop.

Test-Signal was a trill of 7 notes (D5/C5 aka MIDI notes 86/84) in the MIDI recorder of my Kawai DigitalPiano. I replayed that same trill over both chains and then put Pianoteq's logged MIDI-timestamps into a libreoffice spreadsheet.

The timeintervals in ms between those note-on/off in both chains are visualized in the upper diagram.

In the lower diagram the durations of the 7 notes are shown (difference between timestamp note-off and -on in PTQ's MIDI log):

https://i.postimg.cc/tJS8Yw6J/time-intervals-between-note-events.png
https://i.postimg.cc/jjSgJZsJ/note-durations.png

There are up to a few milliseconds variance in the MIDI events and the note durations that the PTQ-soundengine gets.

Whether USBtoUSB or DINtoUSB represents more accurately the test-signal I can't derive from this experiment, because the timestamps in the source file are unknown.

There are theoretical inaccuracies we can expect:

* A minimum  of +/- 1 ms from the resolution of a serial MIDI bus with 31250 bit/s.
* +/- 1 ms from Pianoteq's logging (shown resolution 1 ms).

Unknown is potential MIDI-Jitter in the Kawai.
Unknown is the MIDI-Jitter in the external DINtoUSB-converter.

Keep in mind that one of the chains can have a higher *static offset* in latency than the other, which this experiment is agnostic for (it tracks just relative events in time).

Because inaccuracies seem to exist (at least in this short experiment) it is not a bad idea to take the chain that "feels" better to the pianist

Raw data:
https://i.postimg.cc/jjBHdXCT/table-DINto-USB-accuracy.png

Last edited by groovy (14-12-2019 18:03)

Reply by Shanesplanet

  • Avatar
  • Shanesplanet
  • Member
  • Offline
  • Registered: 19-03-2019
  • Posts: 9

Re: Use a high quality usb cable to get the best velocity response

groovy wrote:

To get an idea of the "MIDI-accuracy" I made an experiment with two different chains.

Chain A: DigitalPiano connected via USBtoUSB with my Pianoteq-Laptop. (my standard setup)
Chain B: DigitalPiano connected via a Miditech DINtoUSB converter with my Pianoteq-Laptop.

Test-Signal was a trill of 7 notes (D5/C5 aka MIDI notes 86/84) in the MIDI recorder of my Kawai DigitalPiano. I replayed that same trill over both chains and then put Pianoteq's logged MIDI-timestamps into a libreoffice spreadsheet.

The timeintervals in ms between those note-on/off in both chains are visualized in the upper diagram.

In the lower diagram the durations of the 7 notes are shown (difference between timestamp note-off and -on in PTQ's MIDI log):

https://i.postimg.cc/tJS8Yw6J/time-intervals-between-note-events.png
https://i.postimg.cc/jjSgJZsJ/note-durations.png


There are up to a few milliseconds variance in the MIDI events and the note durations that the PTQ-soundengine gets.

Whether USBtoUSB or DINtoUSB represents more accurately the test-signal I can't derive from this experiment, because the timestamps in the source file are unknown.

There are theoretical inaccuracies we can expect:

* A minimum  of +/- 1 ms from the resolution of a serial MIDI bus with 31250 bit/s.
* +/- 1 ms from Pianoteq's logging (shown resolution 1 ms).

Unknown is potential MIDI-Jitter in the Kawai.
Unknown is the MIDI-Jitter in the external DINtoUSB-converter.

Keep in mind that one of the chains can have a higher *static offset* in latency than the other, which this experiment is agnostic for (it tracks just relative events in time).

Because inaccuracies seem to exist (at least in this short experiment) it is not a bad idea to take the chain that "feels" better to the pianist

Raw data:
https://i.postimg.cc/jjBHdXCT/table-DINto-USB-accuracy.png

BOOM goes the dynamite! Awesome research and thanks for sharing this! I too notice differences in midi devices and midi>usb converters vs usb to usb. Where I noticed it was when watching clock jitter from daw to hardware, or slight variances on drum machine captures. I never managed to grasp it like you have. I am reluctant to think that a high quality cable would make much difference. Isnt digital data either making it or not, in contrast to how audio works? Perhaps a cable that is bad, will suffer data loss and packets be resent, making it seem like extra latency? If events are timestamped, wouldnt that negate any apparent latency due to packet resend? I really dont know, but I'm sure someone is selling cables, claiming it magically faster than another. In the end, I devise workarounds but still nothing thats absolutely stable. It seems that different companies use different drivers and this also shows variances. I only experience this when using hybrid setups. All of my hardware holds solid and all of my software is solid... when used seperately. The HW that has usb (vs din) out, seems a little tighter, but i bet its the hw usb driver just happens to work better than my motu or roland din to usb. I havent ever noticed higher quality midi or usb cabling to make a difference, so long as the cable works. Quality is usually evident in the durability, over the speed imho.

Last edited by Shanesplanet (14-12-2019 21:52)

Reply by Luc Henrion

  • Avatar
  • Luc Henrion
  • Member
  • Offline
  • Registered: 02-05-2007
  • Posts: 935

Re: Use a high quality usb cable to get the best velocity response

What is measured here is not the quality of an USB cable it's the difference between  only one stream (USB->USB) and a pair of consecutively streams: DIN -> USB (with the necessary conversion), and again USB-> USB. It seems very logical that there is less latency with only one...
Please let the "quality" discussion of digital cables to all those audiophiles out there, swearing they hear the difference between a silver or gold plug ! ;-)

Luc Henrion's Website

Reply by groovy

  • Avatar
  • groovy
  • Member
  • Offline
  • Registered: 12-06-2009
  • Posts: 724

Re: Use a high quality usb cable to get the best velocity response

Thanks for commenting, Shanesplanet.
(could you please remove the unnecessary full-quote?)

Classic DIN-MIDI (5-pin) is unidirectional, i.e. the 5-pin MIDI-output of a keyboard sends data and gets no feedback what happens to it. No resending possible.
When data are lost, there are glitches like hanging notes or interrupts. Unless this occurs, no need for a better shielded or shorter DIN-cable needed in my opinion.

USBtoUSB from keyboard to PC seems to be similar. When MIDI commands are tunneled over USB there probably is no resending implemented, because real-time response is intended. As long as there are no glitches a better or shorter cable should make no difference for data integrity or latency.

Unknown variables are the buffer sizes in external DINtoUSB converters. But attention! Maybe a standard DINtoUSB converter is just hidden inside the DigitalPiano. An internal converter can be better or worse than an external one. Has to be measured.

From Pianoteq's point of view both look the same: USB-MIDI device from Miditech (my external converter) or USB-MIDI device from Kawai (DP internal).

Interesting observation: I can not use the DIN-MIDI-output and USB-MIDI-output of my Kawai at the same time (just one or the other). So my assumption is, that the classic DIN-MIDI output is hardwired with the input of an internal DINtoUSB converter.

Which converter is better then latency- and MIDI-jitter-wise? The external or the internal? Depends on the quality

Reply by RichieBill

  • Avatar
  • RichieBill
  • Member
  • Offline
  • From: Aberdeen, UK
  • Registered: 15-10-2019
  • Posts: 15

Re: Use a high quality usb cable to get the best velocity response

Hi. I use recommended USB cable:
https://www.amazon.co.uk/gp/product/B00...&psc=1
No complaints.

Kawai VPC1 | Arturia Minilab Mk2
Pianoteq 7 Pro | Synthogy Ivory II | Arturia Analog Lab Lite | Korg Collection
Roland Quad Capture | Neumann KH120 | Grado SR225i, SR80e

Reply by groovy

  • Avatar
  • groovy
  • Member
  • Offline
  • Registered: 12-06-2009
  • Posts: 724

Re: Use a high quality usb cable to get the best velocity response

Luc Henrion wrote:

What is measured here is not the quality of an USB cable it's the difference between  only one stream (USB->USB) and a pair of consecutively streams: DIN -> USB (with the necessary conversion), and again USB-> USB. It seems very logical that there is less latency with only one...

Hello Luc,

it is not logical, because we don't know the electronics of the earlier steps in both chains, symbolized by "SomeMagic1" and "SomeMagic2": 

A) Kawai-keyboard-scanning -> SomeMagic1 -> USB-output-Kawai -> USB-cable -> USB-input-PC

B) Kawai-keyboard-scanning -> SomeMagic2 -> DIN-output-Kawai -> DIN-cable -> DINtoUSB-converter -> USB-cable -> USB-input-PC

Moreover, as I wrote in my previous comment, the subchain [SomeMagic1 -> USB-output-Kawai] can probably be replaced with [SomeMagic2 -> DIN-output-Kawai -> DIN-cable -> DINtoUSB-converter]. Then not much is won.

Reply by tmyoung

  • Avatar
  • tmyoung
  • Member
  • Offline
  • From: USA
  • Registered: 20-09-2012
  • Posts: 565

Re: Use a high quality usb cable to get the best velocity response

Very interesting test and results!

I'd be curious if you can confirm from your test strategy that the CPU isn't what's changing the data length.  Since timing differences of 5ms or less could be introduced by the CPU processing instructions at different rates depending on what other tasks are competing for resources or other randomness at the computer-end if you're using PTQ for capture in the test process.  I haven't tested this specifically, but it's possible because the CPU isn't dedicated MIDI hardware, it may introduce some entropy into the data and PTQ wouldn't know the difference.  You could further test this by loading the identical MIDI data multiple times through the same cable and see if there is any jittering/dithering in what PTQ logs.

I would add that in theory USB will outperform most external MIDI-USB converters since the manufacturers of high-end keyboards like Kawai usually use proprietary technologies for capturing keyboard input will already be "digital" in their internal processing rather than the (only slightly) more analog MIDI streams.  The latter will need to be converted "data > MIDI data > data" instead of the simpler "data > data" of USB (at least in theory--every keyboard design and driver will be different).  Plus if there is anything else proprietary in the data stream that doesn't convert to MIDI, it will be lost in that initial conversion, while a system where a direct USB connection with drivers from the keyboard manufacturer would retain any extra information and probably pass it onto PTQ.

It's further possible that there is some reason that MIDI I/O would be different from USB I/O because of the software that interprets technologies like aftertouch or key-up velocity which might be converted to different MIDI data for different reasons, since lifting your finger off a piano key isn't a binary activity but for the purposes of MIDI standards it needs to be.  I am intrigued for example that not all keystrokes are interpreted as faster or slower or longer or shorter, it varies in data which means that one isn't necessarily faster or shorter than another, which could give a window into how non-MIDI data is being converted to MIDI data inside the processing of the keyboard itself.

Spotify: https://open.spotify.com/artist/2xHiPcCsm29R12HX4eXd4J
Pianoteq Studio & Organteq
Casio GP300 & Custom organ console

tmyoung's Website

Reply by groovy

  • Avatar
  • groovy
  • Member
  • Offline
  • Registered: 12-06-2009
  • Posts: 724

Re: Use a high quality usb cable to get the best velocity response

tmyoung wrote:

Very interesting test and results!

I'd be curious if you can confirm from your test strategy that the CPU isn't what's changing the data length.  Since timing differences of 5ms or less could be introduced by the CPU processing instructions at different rates depending on what other tasks are competing for resources or other randomness at the computer-end if you're using PTQ for capture in the test process.  I haven't tested this specifically, but it's possible because the CPU isn't dedicated MIDI hardware, it may introduce some entropy into the data and PTQ wouldn't know the difference.

Yes, I agree, this is not excluded. On the other hand the 37 years old MIDI 1.0 Standard was designed for ~1 ms resolution and it would be odd, if decades later PCs are not logging incoming MIDI-notes with 1 ms precision. But you are right, it is not impossible.     

tmyoung wrote:

You could further test this by loading the identical MIDI data multiple times through the same cable and see if there is any jittering/dithering in what PTQ logs.

Correct. I thought about that, but it is work to read the timestamps from the display and to hack it in a spreadsheet again ;-). Will try when I have more time.

Btw even the MIDI-Recorder of the Kawai could be a source of MIDI-jitter, when it has no stable clocking. Or when it has CPU-load from tone-generation (unless MIDI Local-Off is activated).


tmyoung wrote:

I would add that in theory USB will outperform most external MIDI-USB converters since the manufacturers of high-end keyboards like Kawai usually use proprietary technologies for capturing keyboard input will already be "digital" in their internal processing rather than the (only slightly) more analog MIDI streams.  The latter will need to be converted "data > MIDI data > data" instead of the simpler "data > data" of USB (at least in theory--every keyboard design and driver will be different).  Plus if there is anything else proprietary in the data stream that doesn't convert to MIDI, it will be lost in that initial conversion, while a system where a direct USB connection with drivers from the keyboard manufacturer would retain any extra information and probably pass it onto PTQ.

Possibly just your wishful thinking? ;-)
It is also possible, they took just their long existing standard DIN-MIDI output and stacked a DINtoUSB-converter on it internally. Those converters are cheap.   

tmyoung wrote:

It's further possible that there is some reason that MIDI I/O would be different from USB I/O because of the software that interprets technologies like aftertouch or key-up velocity which might be converted to different MIDI data for different reasons, since lifting your finger off a piano key isn't a binary activity but for the purposes of MIDI standards it needs to be.  I am intrigued for example that not all keystrokes are interpreted as faster or slower or longer or shorter, it varies in data which means that one isn't necessarily faster or shorter than another, which could give a window into how non-MIDI data is being converted to MIDI data inside the processing of the keyboard itself.

MIDI-Filtering and AI ;-) is another story, let's stay for the moment with the simple note-on- and note-off-events we are detecting with PTQ. - Interesting thoughts nonetheless.

Reply by groovy

  • Avatar
  • groovy
  • Member
  • Offline
  • Registered: 12-06-2009
  • Posts: 724

Re: Use a high quality usb cable to get the best velocity response

tmyoung wrote:

You could further test this by loading the identical MIDI data multiple times through the same cable and see if there is any jittering/dithering in what PTQ logs.

Okay, I made two more runs with both MIDI interfaces.

Both MIDI chains A and B seem to have the same accuracy.

https://i.postimg.cc/13YpjmPX/accuracy-MIDI-USBto-USB.png
https://i.postimg.cc/V690mmyj/accuracy-MIDI-DIN-to-USB-converter-miditech-extern.png

Reply by tmyoung

  • Avatar
  • tmyoung
  • Member
  • Offline
  • From: USA
  • Registered: 20-09-2012
  • Posts: 565

Re: Use a high quality usb cable to get the best velocity response

groovy wrote:

Okay, I made two more runs with both MIDI interfaces.

Both MIDI chains A and B seem to have the same accuracy.

Once again, fascinating results and excellent work!  Why do I fear companies will start marketing "special" USB and MIDI cables with humanization built-in?

My conclusion from the results is that using an external and clocked recorder for MIDI is the most reliable solution when extreme accuracy or resolution is needed (like the high-res MIDI piano competitions or scans of piano rolls or something where a global clock makes a difference in sound or workflow), and that any data conversion seems to be happening close enough to light-travel time that both routes are comparable.

Great detective work!

Spotify: https://open.spotify.com/artist/2xHiPcCsm29R12HX4eXd4J
Pianoteq Studio & Organteq
Casio GP300 & Custom organ console

tmyoung's Website

Reply by tmyoung

  • Avatar
  • tmyoung
  • Member
  • Offline
  • From: USA
  • Registered: 20-09-2012
  • Posts: 565

Re: Use a high quality usb cable to get the best velocity response

groovy wrote:

Possibly just your wishful thinking? ;-)
It is also possible, they took just their long existing standard DIN-MIDI output and stacked a DINtoUSB-converter on it internally. Those converters are cheap.

And yes, it seems to be exactly that...wishful thinking...

Spotify: https://open.spotify.com/artist/2xHiPcCsm29R12HX4eXd4J
Pianoteq Studio & Organteq
Casio GP300 & Custom organ console

tmyoung's Website

Reply by groovy

  • Avatar
  • groovy
  • Member
  • Offline
  • Registered: 12-06-2009
  • Posts: 724

Re: Use a high quality usb cable to get the best velocity response

Keep in mind that one of the chains can have a higher *static offset* in latency than the other, which this experiment is agnostic for (it tracks just relative events in time).

That left me curious. Has one of the MIDI chains a higher amount of static latency? Besides the shown random inaccuracy/intrinsic "humanization"? (thanks tmyoung )

Although I cannot measure this offset absolutely, I found a rude method to determine a relation (which path has the higher latency and how much?).

This make use of the MIDI recorder in the Kawai DP. I recorded a single testnote C5 (with auto-record, starts recording as soon as a key is pressed).

The idea is to get two acoustic audiosignals, one from the speaker and one from the mechanical release-klick of the PLAY-button (release of this button stops pausing and fires up the recorded MIDI-note).

The delay between those two acoustic events should be different. when one of the USB-MIDI interfaces has significantly more latency than the other, and can be determined in a wave editor (what I did).

https://i.postimg.cc/7hMmpmVy/DP-MIDI-recorder-to-speaker-latencies.png

My conclusions:

Both USB-MIDI interfaces (the internal USBtoUSB (blue) and the external DINtoUSB (orange)) seem to have the same relative latency offset (~26 ms).

and

The DP onboard sound from the DP onboard speaker (green) has ~10 ms better latency than both Pianoteq chains.

Note: Be aware that those delays contain also the various unknown delays caused by the MIDI recorder and by releasing a spring-loaded button. Not at least the human factor in this manual method.

Last edited by groovy (21-12-2019 17:57)