Mystery solved!

Man, who knew your keyboard hardware problem, easily, might had been solved without any escalation  —but by a simple, local MIDI off?

Nice bit of troubleshooting.  And very interesting info on how an apparently independent midi keyboard can throw things out of whack on a midi setup.  I'd never have expected that.  Hope this lets you get back to using Pianoteq (or whatever you choose) to make the sounds you want.

Ah yes, the joys of the "there's no need to shut down that process - it's doing no harm" logic I have heard so many times in my career.  First thing a programmer should be taught - release resources you are not using.

Yes, you are correct.

Ok, you might have a point here, but the fact is that the notes with the same time-stamp were always the notes that had a audible delay. How I checked:
- Play until I noticed a delay
- Immediately stop and keep my fingers on the keys so I could see which key were 
  pressed. If I had already played notes directly after the delay I checked what my
  previous chord was.
- Check the midi monitor and search for the notes I played that were delayed.
- Check the time-stamp ==> Always exactly the same.
- Start playing again and repeated this test for at least 4 times, same results every time. Two or more notes had the same time-stamp.

Might be, but how long should I try? I've tried > six months now. Never saw anything strange in the midi event viewer.

I'm having a hard time to agree on this one. Simply because the recordings are fine.
I played back the recorded midi data every time I heard a delay, but there was no delay on the recording. To me this implies there must be some sort of timing that is sent. If my recordings had the same delay as the live session I would fully agree with you.

Yes, I did not expected such an answer from Studiologic. I expected that, if I don't play any notes on a channel (or local control is off), the CPU does (almost) nothing.
So it was a bit confusing when I was told the sound engine is always active.
I do understand the decision to give the internal sound engine a higher scheduling priority than the midi engine, but to me the fact that they had to made this decision is proof of poor design.

This is certainly worth a try, but I hope your piano is designed way better than mine is

Yes, it's a bug for sure. I'm tempted to call it a bad design.

The only thing we know for sure in this thread is , that the MIDI protocol does not carry time-stamps. For example the code of a Note-On event consists of 3 bytes for channel, note and velocity (each byte framed in a start- and stop-bit so this event has 30 bit).

... here the dilemma starts: On which side of the cable is the origin of "the delay", sender or receiver?

A) Origin sender, then all delays are captured on the MIDI-recording of the receiver.

B) Origin receiver, then two hardwares (Ipod, Notebook), three OS (iOS, Linux, Windows) and two applications (Pianoteq, Ravenscroft) show the same delay symptoms.

Hypothesis A is tempting at first glance. But you can't hear the delays on the recording, only when playing realtime. - Just an idea: Is it possible that your delays are so small they can only be perceived as long as a reference is present (key touch)? but not without any reference when replaying the recording?

Or is your impression that the delays are so huge everybody could hear them on a recording?

Mystery evolves!

Perhaps, veronica-brooke, another keyword here is Control.

MrRoland, the engine runs possibly in anticipation it might receive MIDI messages (on sixteen {16} available channels) via the keyboard MIDI in.

Local control has no effect on incoming messages!  It happens on the connected device when connected by MIDI cable to your keyboard.

When you’ve a keyboard patch selected, one may assume it’s gotten priorities (from MIDI input circuits) to limited processor resources.

You likely free resources from possible bottle necks whenever you disengage Local control at any selected patch.  Thusly, delays are imperceptible or possibly avoided altogether.

Thank you, MrRoland!

Thanks for your answers, MrRoland!

Interesting, that the Numa Compact 2 does not have the feature "local control off" (else Studiologic would have mentioned it in the MIDI implementation chart of this keyboard).

This MIDI feature decouples the internal keyboard from the internal sound engine, but leaves the MIDI output and input working.

As Amen Ptah Ra mentioned this feature would have been the simplest method to reduce cpu load caused by the internal sound engine. - Strange, that Studiologic doesn't support this long-time standard feature.

Btw I remember, that organ sounds can be quite demanding. When Organteq alpha came out, it overloaded my low-performance-netbook at that time, while normal Pianoteq worked. - Hmm, I should test Organteq alpha after this long time again ...

cheers

Are you sure? What, if they just mute the audio, but keep internal MIDI and audio processing coupled?

... that's normal with "local control off" to keep the engine idle, because receiving MIDI input from external and synthesizing it to audio is wanted.

When no notes are are sent to the engine, there should be no significant cpu-load from the engine. For example a webbrowser makes significant load only, when traffic is made (download sites, uploads etc.). Or compare Pianoteq's perf monitor --> cpu load just when playing notes.

Nobody has seen the CPU-load so far, neither the idle load nor the playing load