But if the keyboard/controller is connected via 5-pin DIN too a standalone USD MIDI interface, you should (usually?) see that higher message frequency in real time.

Yes, that's what I have shown in post 38 of this thread:
https://forum.modartt.com/viewtopic.php...85#p988685

I could play 10 notes in just 6-7 ms with the Goldstar keyboard, that had its 5-pin DIN-MIDI connected via an Edirol USB-MIDI interface to the Pianoteq PC. That is better "realtime" behavior, than a directly USB connected keyboard to the same PC, which needed 10 ms for 10 notes (in other words 1 note per ms average).

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.

Resonses in this thread on the MIDI Association forum seem to support that (i.e. running status is only used across DIN connections and USB interfaces restore the status byte if not present):

https://www.midi.org/forum/5262-running-status

But if the keyboard/controller is connected via 5-pin DIN too a standalone USD MIDI interface, you should (usually?) see that higher message frequency in real time.

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.

Just the receiver should always be able to handle incoming running status streams.

Two questions are open at the moment:

Why do I find just ~1 note event per 1 ms from the Korg in Pianoteq's logging, when the recorded and saved MIDI file of Pianoteq indicates that running status is used? (We would expect 1 note per 2/3 ms)

Is it possible that the data reduction (removing of redundant status bytes) takes place in the moment when the standard midi file is saved? (and not before?)

PPS: And strong indication, that the Korg B2 is using (like the most DP?) what I called "hybrid" running status just for illustration. Pressing and releasing a chord I saw a running status for the Note-On Status byte and a running status for the explicit Note-Off Status Byte in the recorded MIDI file. New hypothesis: All MIDI keyboards that send explicit Note-Off velocities are using running status

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.

With my other Korg keyboard both Note-On and Note-Off Status Bytes are in the recorded MIDI file.

If the data were rewritten to standard Note-Off events by Pianoteq, I would have expected to see that in the recorded MIDI data.

PPS: And strong indication, that the Korg B2 is using (like the most DP?) what I called "hybrid" running status just for illustration. Pressing and releasing a chord I saw a running status for the Note-On Status byte and a running status for the explicit Note-Off Status Byte in the recorded MIDI file. New hypothesis: All MIDI keyboards that send explicit Note-Off velocities are using running status

If you're going to implement Note Off velocity and still have the efficiency of running status, that's exactly what you would need to do.

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

Each additional Note-Off status byte would reduce that efficiency.

Yes, but it's not "Impossible"  to use both Note Offs and running status. If you're going to implement Note Off velocity and still have the efficiency of running status, that's exactly what you would need to do.

From the standpoint of efficiency, I think it's more likely that the monitor works in parallel to render the MIDI input to text while the engine renders the raw MIDI to sound. Presenting Note Ons as Note Offs is probably just to the user in distinguishing "Off"s from Ons at a glance.

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?

brundlefly wrote:

Yes, Cakewalk uses running status and actual Note Offs, but Note Off velocity is fixed at 0.

Are you sure?
That should be impossible. The principle of "running status" is that real note-off status bytes are omitted. Just note-on status bytes are used and the end of a note is simulated by note-on with velocity 0.

I believe that's a misinterpretation. The purpose of running status is to send a status byte only when the status changes, and it is not limited to Note On/Off messages, In fact it's arguably more important for transmitting Continuous Controller messages which tend to have a higher density than Note messages. So in my test there would be is a series of Note Ons that require no change in status after the first, then a change to Note Off followed by a series of additional Note Offs that require no status byte.

That said, however, I confirmed CW is sending Note On with velocity 0 and Pianoteq's monitor is reporting it as "Note Off".

In any case, My intent was primarily to show that both Pianoteq 7 and 8 are capturing note timings down to a resolution of 1ms, and neither is quantizing the closely-spaced notes of a chord to the same timestamp as suggested by the OP.

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, Cakewalk uses running status and actual Note Offs, but Note Off velocity is fixed at 0.

Are you sure?
That should be impossible. The principle of "running status" is that real note-off status bytes are omitted. Just note-on status bytes are used and the end of a note is simulated by note-on with velocity 0.

I did the same with Pianoteq 7 and observed no differences in timestamping or sound.

Bottom line: Both Pianoteq 7 and 8 appear to processing MIDI Note Ons at the limit of MIDI 1.0 message transmission frequency.

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

Pianoteq pretty consistently time-stamped the 36 notes across a range of only 24 milliseconds with many notes on the same timestamp - call it 2/3 of a millisecond per message.

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?