Keyboard sampling freq

I have a smaller cousin of the digital piano you have. And it happens here too. I suspect this is more of a limitation of USB polling rates. Default is generally 125 Hz on windows which would translate to 8ms. I am not sure if midi input is polled higher or not. I couldn't find any info or any way to change that. My mouse and keyboard drivers let me increase it to 1000 Hz though but that's only for these two devices.
Midi standard would also have something to do with this. Perhaps more tech savvy people here would know better.

I dont know if it helps:
USB2 is capable of 8kHz polling rate.
Depending on your OS, and on the Midi device connected, you may change the polling rate.
On Linux (Ubuntu in my case) there are multiple options - some prefer to hack around the original files of the OS or recompile kernels,
but I just use a low latency kernel that is set to 1000hz clock time,
and ontop I use libinput-tools which can set overrides for sepecific USB ports or globaly. Install it, and than open some shell and enter

Check for your desired sysname (the port its connected to)

Check here what Device Type you are looking for

than create an override config by

and put the following command in it:

Restart the service by

This should give you down to 0.125ms capabilities.

Cheers

installed - trying: cannot identify the usb MIDI (I must be missing it)

run debug-events:
- mouse events!
- computer keyboard events!
- page turner events!
- press the piano keyboard - no events...
--- close Pianoteq - still no events...

any ideas?
anyway it goes I thank you again for your post with lots of information!

Dont think I forgot about it, but Im actually more busy than expected this weekend - but I will definitely get back to you again!

I am actually very intrigued to hear that a CLP can produce perfect simultaneous notes given the internal protocol is midi . Midi as far as I know is at the same time a format and a protocol and as a protocol it is serial, which means that only one note can be transmitted on a given channel at instant t . It is actually not a limitation as the delta time between 2 events is more or less of the same magnitude that the actual real delta when your fingers press 2 notes or more, at the same time, on the piano . Perfect synchro is an ideal for the fingers but doesn’t exist in reality and this is actually important as it is all about ‘humanisation’ of a rendition . So , while I think it is actually possible for a sofware ( VST or internal piano software) to group notes that events separated by 1ms or less and group them as sounds that have to be rendered simultaneously via polyphony , it seems to me , like a ‘false’ good idea as it doesn’t reproduce the real human asynchronous input . Maybe , I’m wrong as I only writing this based on what I know . So feel free to correct me.

My question came about because I have no access to a strings and hammers piano - so I can't compare.

There is no doubt that I did try a small Yamaha (CLP, CVP. Arius... one of them) where it was actually difficult not to play the chords perfectly simultaneously.
I remember asking Brian (I think is name is Brian) on the piano store about it - this was 5 or more years ago.

yes, I thought that's why the Yamaha CLPs sound strange to me (again over YT - but others sound normal)
and that's how this question started... I don't think you're wrong. It's not natural.

in Pianoteq / options / MIDI I did get two notes reported on the same millisecond.
Could not do it with 3 notes - let me try again... this time I got reported:
- 1 ms for 2 notes
- 0 ms for releasing 2 notes
- 4 ms for 3 notes

yes, that's what I did.
in this case 73.256 - 73.256 <= 0.999999999...999 ms or < 0.5 ms with rounding...

Don't know, unclear what the author did there. But I freely adapted the idea of 10 fingers.

I pressed 10 white keys (C3-E4) at once with a folding rule.
I wrote down the timestamp of PTQ's midi monitor of the first and the last of that ten note-on events. Five repetitions:

613 ms, 623 ms, delta 10 ms
458 ms, 470 ms, delta 12 ms
918 ms, 933 ms, delta 15 ms
141 ms, 151 ms, delta 10 ms
684 ms, 696 ms, delta 12 ms

The smallest delta for ten notes has been 10 ms, so I think my system is using the standard ~1 ms MIDI 1.0 resolution per event.

The keyboard is directly connected per USB with my Linux laptop and Pianoteq 8 STD.

Audio and midi is served by the standard kernel module "snd-usb-audio". The audio and midi device in my Korg B2 is a USB 2.00 device for example:

bcdUSB               2.00
Bus 001 Device 005: ID 0944:020f KORG, Inc. B2

This USB Device 005 is used like a USB 1.1 device with "Full Speed" of 12 Mbit/s by the driver:

lsusb -t
...
    |__ Port 3: Dev 5, If 4, Class=Audio, Driver=snd-usb-audio, 12M
    |__ Port 3: Dev 5, If 2, Class=Audio, Driver=snd-usb-audio, 12M
    |__ Port 3: Dev 5, If 0, Class=Audio, Driver=snd-usb-audio, 12M
    |__ Port 3: Dev 5, If 3, Class=Audio, Driver=snd-usb-audio, 12M
    |__ Port 3: Dev 5, If 1, Class=Audio, Driver=snd-usb-audio, 12M
...

The midi input of the alsa driver snd-usb-audio is used by the Process ID 1284, which is Pianoteq in this moment:

cat /proc/asound/B2/midi0

B2

Output 0
  Tx bytes     : 0
Input 0
  Rx bytes     : 690
  Owner PID    : 1284
  Buffer size  : 4096
  Avail        : 0
  Overruns     : 0

Each time I press a key the counter Rx bytes is increased by 3 bytes (note on) and 3 bytes (note off) as expected.

Full Speed USB is using the USB frame period of 1 ms. As far as I know each 1 ms frame transports a payload of 1023 bytes (forgot the details, have to check that!). That's a lot midi events per frame.

Interesting is the line "Buffer size  : 4096" in the upper code block. I don't fully understand, if this means the Input Buffer of the driver buffers 4 USB frames. That would mean a minimum 4 ms latency via the USB hop. (In the context of USB Audio I read in past an 1 ms frame is normally buffered with 2 frames in the USB device and 2 frames in the USB host, which also makes 4 ms in sum).

Hi Antonio

... eventually that is "MIDI active sensing", which sends keepalives each 0.3 s. If your unknown midi events are not shown in Pianoteq's midi monitor, then it probably is MIDI active sensing.

... that is the expected result in my opinion. Twenty note-offs in 20 ms means 1 event per 1 ms at best.

Late Edit:

After reading a bit in the USB protocol at
https://www.beyondlogic.org/usbnutshell/usb4.shtml
the MaxPacketSize is 64 bytes (and not 1023 bytes), because the Transfer Type for USB MIDI is Bulk (and not Isochronous like AUDIO):

$ lsusb -v -s 001:005
...
   Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        4
      bAlternateSetting       0
      bNumEndpoints           2
      bInterfaceClass         1 Audio
      bInterfaceSubClass      3 MIDI Streaming
      bInterfaceProtocol      0 
      iInterface              0 
      MIDIStreaming Interface Descriptor:
        bLength                 7
        bDescriptorType        36
        bDescriptorSubtype      1 (HEADER)
        bcdADC               1.00
        wTotalLength       0x0025
      MIDIStreaming Interface Descriptor:
        bLength                 6
        bDescriptorType        36
        bDescriptorSubtype      2 (MIDI_IN_JACK)
        bJackType               1 Embedded
        bJackID                16
        iJack                   3 
      MIDIStreaming Interface Descriptor:
        bLength                 9
        bDescriptorType        36
        bDescriptorSubtype      3 (MIDI_OUT_JACK)
        bJackType               2 External
        bJackID                64
        bNrInputPins            1
        baSourceID( 0)         16
        BaSourcePin( 0)         1
        iJack                   0 
      MIDIStreaming Interface Descriptor:
        bLength                 9
        bDescriptorType        36
        bDescriptorSubtype      3 (MIDI_OUT_JACK)
        bJackType               1 Embedded
        bJackID                48
        bNrInputPins            1
        baSourceID( 0)         32
        BaSourcePin( 0)         1
        iJack                   4 
      MIDIStreaming Interface Descriptor:
        bLength                 6
        bDescriptorType        36
        bDescriptorSubtype      2 (MIDI_IN_JACK)
        bJackType               2 External
        bJackID                32
        iJack                   0 
      Endpoint Descriptor:
        bLength                 9
        bDescriptorType         5
        bEndpointAddress     0x02  EP 2 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval               0
        bRefresh                0
        bSynchAddress           0
        MIDIStreaming Endpoint Descriptor:
          bLength                 5
          bDescriptorType        37
          bDescriptorSubtype      1 (GENERAL)
          bNumEmbMIDIJack         1
          baAssocJackID( 0)      16
      Endpoint Descriptor:
        bLength                 9
        bDescriptorType         5
        bEndpointAddress     0x82  EP 2 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval               0
        bRefresh                0
        bSynchAddress           0
        MIDIStreaming Endpoint Descriptor:
          bLength                 5
          bDescriptorType        37
          bDescriptorSubtype      1 (GENERAL)
          bNumEmbMIDIJack         1
          baAssocJackID( 0)      48

A MaxPacketSize of 64 bytes means there are much less MIDI events in an USB frame period of 1 ms (remember a note-on has 3 bytes plus start and stop bits each byte in the MIDI1.0 protocol).

With your link to usb.org I found one more overseen component, thank you!
The 3-byte MIDI events are first converted to "32-bit USB-MIDI Event Packets" (4-byte), before they are sent in a bulk transfer via USB-cable to the PC. I assume these  "32-bit USB-MIDI Event Packets" are the payload of the earlier mentioned 64-byte bulk packets (correct?). And a 1 ms USB frame can contain several of those 64-byte bulk packets (true?).

At least the most important question is:
Where in the whole USB picture is the bottleneck, that limits the effective rate to 1 MIDI event per 1 ms we see in Pianoteq's midi monitor?

USB 1.1 seems not to be the limiting factor, because even one 64-byte bulk packet can contain roundabout sixteen 4-byte USB-MIDI Event Packets. Because of some overhead probably less than 16 USB-MIDI Event Packets. But 10 note-on events per 64-byte bulk packet are possible I think. And when there are more 64-byte bulk packets possible in a 1 ms USB frame, then it is very easy to transport say 10 notes in 1 ms with USB 1.1.

Ergo the "serialisation" to 1 note per 1 ms happens outside the USB protocol. My guess is a normal MIDI 1.0 stream inside the keyboard (here Korg) to its internal USB converter (aka USB-MIDI interface).

A second possibility for the bottleneck would be the MIDI 1.0 stream after the incoming USB frames are reconverted in the ALSA USB MIDI driver inside the PC. But I guess at the PC side only the original sequence of MIDI events of the source (keyboard) is recovered.

Sorry for the speculations, the whole picture is not easy to understand and express for me. But it is getting clearer ...

It seems the work has already been done. There many factors to consider, including the keyboard itself.

https://link.springer.com/article/10.37...018-1042-7

If usb 2.0 is used, the connected device positions itself as an audio device and the descriptors are correct, then the message can fly to the computer with a delay of 20-30 μs.  I observed this using the analyzer when I created a midi device from stm32.  A package can contain several midi events at once.  Defining device descriptors as an audio class causes the usb host to poll the device for messages at a high frequency.

I don't know what speeds are used in different digital piano controllers. But the following speeds are achievable for midi transfer via usb, this can be seen from the screenshots of the analyzer window:

(Here I am looking at what is going on between stm32 and computer)

Here the device has connected but no messages have been sent yet:

Here the device started being interrogated as an audio midi:

At the beginning there is a data packet with a midi message, and then there is a subsequent poll for the presence of data:
(It can be seen that the polling rate is quite high)

The message itself:

On the screenshots, you can see after what time intervals it is possible to send / receive data. This high polling rate starts after the first message is sent.  A data packet can contain several midi messages at once.
Somehow this is faster than the spec you mentioned. I don't know, but it's how it is..
(It feels like Kawai VPC1 is somehow not perfect with speeds. I haven't tested in detail..)

What you show in the last pic is the data rate of the usb bus to the usb controller , not the actual polling rate or latency to the computer buffer, but even with the (slower) isyncronous standard high speed usb is capable of 65.5Mbits/sec or about 8 Bytes /uSec. You show a lower rate. I doubt that the midi data is sent in the isyncronous mode. It is more likely midi is sent in an asyncronous mode i.e. usb controllers transfer data, and the controller is polled by the OS, gets the data when ready and buffers it.

Here is how I see it. When we press a key a few bytes of midi data are sent with some minimum latency between (usb) hardware components which probably has its own buffers so multiple midi packets could be waiting between polls. The OS polls at a set rate, possibly what you have captured in the earlier pictures. I suspect the kernel itself does the polling. The midi receiving thread must wait (sleep) until signaled and (the kernel must be using a cpu to do this). No thread, not even the kernel has its own dedicated cpu and it is likely that the waiting thread must wait for the kernel to first restore it to a running state on the next 'available' cpu before the data is actually sent from the OS buffer. Of course, priorities also come into play. This is quite oversimplified and does not account for additional delays. It should be instructive to play a midi and run (Linux) atop. Hit "y" to see thread mode, notice the cpu idle time and how often Pianoteq's threads are in a sleeping (S), not a running state. There is quite a lot going on 'under the hood' that can and does influence latency.

Good point. I did not notice that.  It also means that the 12Mbits/s includes overhead of the usb protocol.

Probably the Cakewalk MIDI sequencer is using a trick in the MIDI protocol, called "Running Status":

"Only if only grade values are transferred in faster succession and instead of the explicit note-off command a note-on command with a dynamic value 0 is used, the transmission of the status bytes can be dispensed with (running status). However, the amount of data to be transmitted for this block only drops by 1/3."

"If a data byte comes instead of an expected status byte, the last status byte is considered repeated and the current data byte is one of its data (running status)."

(Google translate of https://de.wikipedia.org/wiki/MIDI )

Is cakewalk using note-on with velocity 0 instead of the usual note-off?

thank you!

I kinda guessed that.
The perception of these details on the sound depend on so many factors that we can easily dismiss if not used to these analyses...

... I installed midisnoop, that is showing "Running status" more clearly. MIDI source is an decades old korean keyboard with 49 keys and a 5-pin-DIN MIDI output, connected with an Edirol UM-1SX USB-MIDI-converter to my laptop.

Experiment was again to press 10 notes simultaneously (with the folding rule).
The first 10 events are the Note On events in a delta of 6ms.

Then I released the keys simultaneously and got 10 release events with Note On and Velocity 0. The time delta for all releases is 7 ms.

The "Running status" MIDI data reduction/compression of the keyboard controller had reduced the standard delta of 10 ms to 6-7 ms (a factor ~2/3).

Pianoteq interpretes the event 'Note On with Velocity 0' semantically as Note Off Velocity 0 in its event logger, which is ok in my opinion.

Yes, of course Runnings Status is not limited to Note On/Off status bytes. I know that and just abbreviated and simplified it in one sentence for this thread about the polyphony of played MIDI notes.

When playing just MIDI notes on a keyboard one single Note-On status byte is sufficient to play eternally with the highest "compression" rate of ~2/3. Each additional Note-Off status byte would reduce that efficiency.

In the first post a Yamaha CLP-120 is mentioned. It seems to work like my Korean keyboard. The Yamaha cannot send Note-Off status bytes (8nH). It "only" sends Note-On status bytes with velocity 0 (9nH, v=0) and therefore probably is using Running Status:

Midi implementation chart CLP-120:

(the 2nd column)

... thinking over it, it also could be more than just unprecise reporting in Pianoteq's monitor.
It is possible Pianoteq rewrites the incoming Note-On-velocity-0 events to Note-Off-velocity-0 events, sends them to the soundengine and presents this new MIDI event in the logger.

What do you think?

... it just wouldn't make much sense in a played MIDI keyboard, because every released key then has to generate a Note Off Status Byte in the first place. And then the following running status just survives until the next Note On Status Byte arrives. The running status would be steadily interrupted and "decompressed" by new played keys. - But maybe somewhere in the world a keyboard exists, that is doing this hybrid method, who knows?
(the shown Yamaha and Goldstar don't)
 

Yes, but a parallel logging and soundprocessing could also happen when the incoming MIDI event has been rewritten previously to real Note Off (and not just cosmetically) - Probably only Modartt knows the facts.

What I was trying to convey earlier is that this is just garden-variety running status - a status byte is sent only when the status changes, and the implementation of running status is indpendent of whether Note Offs are used or not.

Things clear up after looking into the USB data with wireshark and usbmon. The USB connection expands each note event to complete 3 byte messages (no 2 byte running status notes exist in the USB path). The acceleration happens earlier over the 5-pin serial line between Goldstar keyboard and USB-MIDI converter (running status compression).

When the 3 byte messages arrive at the PC and are saved to standard midi file format, they are saved in the data reduced form using the running status method already known.

Alsa tools like amidi and aseqdump show the expanded note messages how they arrive with the USB packets. Like Pianoteq the alsa tool aseqdump translates Note-On vel 0 to the term "Note Off" in the monitoring.   

Because the Korg B2 is directly connected via USB with the PC and complete 3 byte Note-On/Off messages are visible inside the USB frames, the Korg is probably not using running status internally.