Hello
I have encountered issues like this in a variety of setups. Unfortunately truly analyzing the issue requires engaging seriously with the concept of "time" as both a musical value (tempo-relative, perceptual) and as an exact "position" vis-a-vis, for example, a computer's cpu clock or a DAW sequencer grid.
To start let's clarify "early". In this thread we are discussing live (human or machine) MIDI output into a DAW. Since each MIDI event is sent into the DAW for processing these events cannot be "early." They are sent at some exact time.
So, we are looking at how the DAW transport has translated these live MIDI events into a position in the DAW session timeline. This positioning is finalized after live input and the transport are sopped. MIDI events input to the DAW are timestamped with an exact time that is somehow related to the cpu clock, and that time is digested by the DAW into a transport location.
In this case the result is that the transport location is consistently "early" in musical time. Since human perception of musical synchrony is widely varied, the usual situation is that the human player has played early, sees the recording is early, and assigned this issue to software.
I suggest that, in most cases, if it's desired that live input start "exactly" on some point in the transport, use quantize either on input or after recording. It's a waste of energy to expect either human performance or the DAW's translation of that performance to adhere to a grid without explicitly telling that DAW what to do.
In an earlier test on this thread human error was compensated for using machine output. OK. So the DAW is placing these incoming MIDI events early. How early? If it is a fairly common rhythmic structure and just a few ticks early, would applying quantize solve the issue? If so, quantize.
Sometimes quantize is undesireable or unrealistic, for example when complex rhythms are needed or the user simply wants the MIDI to appear accurate "right away." In this case adjusting buffer settings, or changing live input options, can help make the translation from livi MIDI input to sequencer gird tighter.
I think some DAW and application designers choose to apply latency compensation at the point of MIDI print-to-sequencer-grid rather than after MIDI execution and before audio output. Rewire implementations, for example, consistently output MIDI early to compensate for audio latency. In Logic X some software instrument plugins hold live MIDI input for an audio buffer duration, causing late MIDI. It would be nice if audio latency compensartion happened only in the audio thread and never in the MIDI processing area.
These inaccuracies can be hadged against but never fully removed. Consider the complexity--the DAW and the plugin softwares within the DAW has to rectify CPU clock time and musical transport time, and also has to process incoming MIDI input that will arrive at an unknown time. As a result all software has to "fudge" something. The result is not dissimlar to a solo performer, say an oboist, playing to an audience in a large concert hall. The oboe is making sound at a mesaurable point in time. Acoustics, human perception, and the speed of sound invariably result in each audience member interpreting the oboe's output at microscopically different times.
I suggest here that most "early" or "late" seeming MIDI input is the result of natural human timing. In cases where the "early" or "late" representations of live MIDI input are the result of machine or software behavior some tolerance for necessary processing activity should be tolerated by the user. I'd guess that 99% of this can be immediately solved by quantization. The remaining 1% may simply require the user to manually position the MIDI data.