Finally, today I got into my VPC1 with a signal analyzer. It was very interesting to find out if there is any internal delay between the activation of the third key sensor and the sending of MIDI data via USB.
And here is the result:
It can be seen that the delay is 2-3 milliseconds. On average. Once, even 0.5 milliseconds. Well, let it be if it was consistently the same. But it is unpredictably different. This makes it difficult to play. It seems to me that this is pretty bad.
scherbakov.al it can be due to the USB protocol. I think I read somewhere that those packets have 1ms delay on average, they can’t be sent instantaneously. Have you measured the delay when using the DIN MIDI ports?
The host (computer) polls the device (VPC1) every 30-50 microseconds for messages. In fact, you can send messages every 30-50 (sometimes 100 us) microseconds, if the length of the message allows. 1 ms is the polling frequency for computer keyboard or mouse(CDC) type devices. For example, my homemade controller sends a message to the computer after just 30-50 microseconds. 2-3 milliseconds is pretty bad, it seems to me.
If it were stable, for example 1 millisecond. It's bad that it's always different.
DIN was not measured.
scherbakov.al DIN was not measured.
I'd be curious to know if there is a difference, but then you'd have to add another level of interface since your computer doesn't have midi-DIN connections. I'm currently running midi via DIN because my Numa was having USB connection problems. I'm using an external USB audio interface that has midi-DIN connections as well. However, this brand (Babyface) is supposed to have the lowest latency in the industry.
God Bless,
David
end to end latency after the VST engine then sound driver output, no way you'll notice.
acoustic piano delays are way higher than that. which is why acoustic pianos = obsolete.
David B DIN was not measured.
I'd be curious to know if there is a difference
It would be interesting to see if the MIDI and DIN outputs have the same timing on the VPC1.
The co-author of the USB Midi spec had a general view for equipment on the market (which might answer some of the questions of @scherbakov.al
The current USB MIDI specification defines the difference between a 5pinDIN connection (31.25kbaud) and a higher speed direct connection. The spec could be improved in that regard, now looking in hindsight 20 years (!) later. But the bigger problem is that most operating system APIs don't use that part of the specification. Devices can send data into the Host at high speed, although you are never sure what your destination software can handle. Many (most?) software applications throttle all data to 31.25 when sending out of the Host to any port because they don't know what the destination can handle.
https://gearspace.com/board/showpost.php?p=13786652&postcount=37
Absolutely not sure of that 😅
I have a midi optical sensor rail under the keys of my acoustic upright and let me tell you that timing inaccuracies are very perceptible, particularly when playing repeated chords. Notes falling before or after the polling are not in the same packet and you can hear it.
Paulo, your hands are not machined steel, and your muscles are not cnc servos, when you play a chord, none of the notes line up exactly in a chord.
if you wanted them in the same packet, the piano would have to make polling rates 100ms+, and make assumptions about what you played.
as for whether you can hear this, i believe you when you say you can tease out some differences under critical listening, i just want to point out that this difference is end to end latency and not merely input latency. there is a huge amount of software and driver latency throughout.
Maybe could do similar tests using a parallel port, or parallel port card for the data acquisition.
Ah, I couldn't measure it with the midi-din output. Perhaps the output is disabled inside the vpc itself. And to enable it, you need to use the vpc-editor program, which only works on Mac and Windows. And I have Linux. To be honest, I’m too lazy to install Windows as a second system for this measurement. I tried running vpc-editor through the wine emulator - in this situation, this vpc-editor cannot see kawai as an external usb device. And, accordingly, it is impossible to change the internal vpc settings. Alternatively, I'll try running Windows in a virtual machine later. Well, or, in case someone’s MacBook or WindowsBook suddenly flies past me, I’ll turn on the din-output inside the vpc for tests. Or another option - maybe to start working the din output you need to ground or pull up some leg of the din cord to the power supply. I don’t remember exactly about this.
About delays.. yes, there will still be delays in the computer when processing and filling the buffer, but they will presumably be predictably the same. And you can get used to it. Like organists, they have relatively long delays until the column of air begins to move. And you get used to it. But the piano (if you play with a piano sound) has a more pronounced and specific attack. And in the chain of delays, suddenly the keyboard creates a rattling noise of the length of the delay. Imagine that when you play, with each key press you will change in an arbitrary way, for example, the buffer size and, accordingly, the delay. In such a situation, the game will feel like walking on a wobbly, bouncing surface. Have you tried walking on a jumping bridge? Even a slight vibration of the surface will throw off your stride in unpredictable ways. You will start to stumble. The changing response delay behaves the same way for fingers. Let it be predictably stable, then ok. And this is even despite the floating delay value of acoustic instruments. Floating depending on speed. You quickly adapt to acoustic ones and this delay becomes predictable and manageable. And sometimes even interesting and exciting. And here, summing up the buffers and sound flight, let there be a delay of 4 ms. And with each press you will have either a 3.5ms delay or a 5ms delay. And this is unpredictable and uncontrollable. This is bad.
And this floating delay is strange, because... calculations of speeds, application of curves, all sorts of calculations... let them have calculations of sine, root, logarithm, many divisions... all this, even on microprocessors with low operating frequencies, can be calculated in a time of up to 1 ms. And be stable over time. And let vpc have some delay, but let it always be the same. Would be better.
scherbakov.al Or another option - maybe to start working the din output you need to ground or pull up some leg of the din cord to the power supply. I don’t remember exactly about this.
Thank you for trying. I can run my Numa via USB midi as opposed to Midi DIN. I chose the DIN because I was having some problems with the USB audio interface on the Numa. However, that has been resolved by using the external Babyface Pro. Currently, I have the option to run midi both via USB (direct to computer from Numa) or midi-DIN (from Numa through Babyface). I think I might switch to midi USB direct to my computer from the Numa. That will do away with some of the bulkiness of the midi-DIN cables.
Also, I guess it's converting to USB anyways since the Babyface is connected to my computer via USB. I would imagine it would be a smoother operation going from Numa Midi USB straight to computer rather than midi-DIN from numa to Babyface and then convert to USB midi to computer. Thanks for getting me thinking about this stuff even though I really don't understand what I'm talking about. 😀
God bless,
David
This is only a comment about playability etc. David L uses vpc1 right? And other people. If they do, then do they encounter latency issues to any extent that that makes the user feel that there is something wrong with the note timing, relative to playing other midi controllers?
SouthPark I don't find any issues, but my playing is nowhere close to @David Lai playing, so I am also interested in hearing from him
The only “delay” there can be on an acoustic piano is for the sound that has to travel to your ears. It takes 1ms for the sound to travel 34cm. It would be the same with digital piano speakers (but on a DP there’s additional delay such as keyboard scanning, audio buffering, etc.). No way a real piano has higher delay than a digital piano, that’s BS 🤣
it depends on where you start counting, if you count finger touch, key travel @ 0 mm, there is significant delay on acoustic piano.
Presumably, triggering the 3rd sensor is equivalent to touching a string with a hammer. It seems so.
On an acoustic piano the blow distance (distance of hammer at rest to string) is usually 47mm. The hammer is detached at escapement which is 1mm before the string. The key has a total travel of 10mm, however the escapement is also 1mm before bottom. However the ratio of hammer travel to key travel is 46 / 9 ≈ 5. That means that for the last 1mm of key travel the hammer should travel 5mm. But it travels only 1mm to the string. Hence, the hammer hits the string before the key bottoms out. I’m not sure where they put the lowest sensor on a digital piano but I’m sure it’s near the bottom. I doubt a digital piano will thus generate a strike event sooner than an acoustic piano. I’m not even sure that’s something good either. But there’s also scanning logic delay. And sound buffering delay.
In an acoustic instrument, the moment of impact of the hammer can be either before the key reaches the bottom, or after. It depends on the style of the game. For a numeric keypad, this time between the hammer stroke and the bottom of the key is most often the same.
BTW, that last millimeter of key travel after escapement is called aftertouch and is variable, depends on pianist preference, apparently the fine timing advance between hammer hitting the string and key bottoming out is important and affects touch perception. DP manufacturers don’t talk about that because apparently the scanning speed introduces some rather unpredictable delay that might be higher than the fine aftertouch setting on an acoustic piano.
