brundlefly
The reply I got was essentially that since a soft synth might be driven by live MIDI input and existing MIDI playback at the same time, it's not possible to apply latency compensation to synth recording

Makes sense. No one has introduced a feature like midi latency compensation coz the soft synth might get live input and playback from existing midi notes as well at the same time. That again proves what I found out and posted. Recording has latency playback doesn't. If compensation has to be created it should be created only for live input and not to the existing midi notes. Is that so impossible? Must be! if its it possible we would have had such a feature now in every daws for years! But to me this still looks pretty simple. This feature can be introduced same as the quantize feature. After recording the midi notes instead of selecting the notes a applying quantize, users can select the notes and apply 'latency compensation' to the notes so that the recorded notes move forward the no of ms required. Should be a great new feature. Hope the bakers implement this. 
 

Interesting idea for a feature request... 
 
http://forum.cakewalk.com/Features-Ideas-f76.aspx

I have the same problem that I think you have.  Whether it's because I play the keys slightly ahead of where I want to, or because of the latency, i've found a simple fix.
I highlight ALL the MIDI data in the track, and simply drag it all later (to where the first note SHOULD strike).  Then, the timing issue has been corrected, while the playing is still real and un-quantized.

sonarman1

brundlefly
The reply I got was essentially that since a soft synth might be driven by live MIDI input and existing MIDI playback at the same time, it's not possible to apply latency compensation to synth recording

Makes sense. No one has introduced a feature like midi latency compensation coz the soft synth might get live input and playback from existing midi notes as well at the same time. That again proves what I found out and posted. Recording has latency playback doesn't. If compensation has to be created it should be created only for live input and not to the existing midi notes. Is that so impossible? Must be! if its it possible we would have had such a feature now in every daws for years! But to me this still looks pretty simple. This feature can be introduced same as the quantize feature. After recording the midi notes instead of selecting the notes a applying quantize, users can select the notes and apply 'latency compensation' to the notes so that the recorded notes move forward the no of ms required. Should be a great new feature. Hope the bakers implement this. 
 

 
This is not about "MIDI latency" it's about compensation for audio latency. And audio buffering affects playback as well as recording latency. Here's the explanation direct from the proverbial 'horse's mouth', regarding why soft synth recording isn't compensated:
 
We don't latency compensate synth ports.  Soft synth inputs are treated differently from hardware inputs.
Why are they different? A virtual synth port has audio that can be triggered by sequenced MIDI as well as live MIDI. 
Sequenced MIDI is cooked ahead of time and is always available exactly at the time that the buffer is processed. Hence there is no need for output latency compensation. In fact if we attempted to compensate the recorded audio it would be out of time (earlier) compared to the sequenced MIDI.

Since a synth port can contain audio from live MIDI as well as sequenced MIDI we cant apply a one size fits all approach here. When doing synth recording with live inputs you need to record at the lowest latency possible to avoid the audio delay.
 
I have to admit on re-thinking this that it should still be possible to compensate the latency of soft synth audio from merged sequenced and live  MIDI input after the fact by sliding the recorded audio earlier in timeline, as is done with regular audio inputs, so this might need to be revisited. But since it's not possible to avoid monitoring latency of soft synths by direct-monitoring the instrument's output as you can with external audio input, you will necessarily have to be recording with low latency so this really shouldn't be an issue.
 

@brundlefly 

Yes wrong terminology used technically its not midi latency. May be audio roundtrip latency is the right word?

We don't latency compensate synth ports.  Soft synth inputs are treated differently from hardware inputs.
Why are they different? A virtual synth port has audio that can be triggered by sequenced MIDI as well as live MIDI. 
Sequenced MIDI is cooked ahead of time and is always available exactly at the time that the buffer is processed. Hence there is no need for output latency compensation. In fact if we attempted to compensate the recorded audio it would be out of time (earlier) compared to the sequenced MIDI.

That's exactly what I have noticed and I have been telling. Having a compensation in the output of synth port will only mess up things more coz the playback of midi sequences has no latency (as they dont have to go through the roundtrip I guess) Only the live midi input has the latency. This is probably the reason why this compensation had never been implemented. 

I have to admit on re-thinking this that it should still be possible to compensate the latency of soft synth audio from merged sequenced and live  MIDI input after the fact by sliding the recorded audio earlier in timeline, as is done with regular audio inputs, so this might need to be revisited.

That would be great if the live midi alone can be compensated. But if that's possible why had no one implemented it yet. So I believe may be that's not possible at all.

But since it's not possible to avoid monitoring latency of soft synths by direct-monitoring the instrument's output as you can with external audio input, you will necessarily have to be recording with low latency so this really shouldn't be an issue.

You are right. When that is the case its essential to be recording with low latency. To me that's not really the issue. (Coz we have automatic brain compensation )  With 30-40milli sec latency or even more! I have no problem at all in playing down the stuffs I need. I guess no one will find that a problem. With a buffer size of 512samples in ASIO i get only 31ms latency. I have never needed to keep  the buffer size higher than 750samples. So an average 30-40ms of latency is what the worst latency everyone can get (Unless their system specification is way to bad or they have kept the buffer size or some other setting way to high)(Most users have latencies lower than 10ms). while recording with a 30-40ms latency we don't even notice any delay.  Our brain compensates by itself by accurately playing the notes 30-40milli sec ahead. Pretty awesome really  It just happens automatically. This compensation our brain brilliantly does to override the latency goes wasted when the recorded midi is played back without latency. That's where we have the issue now. During playback we gotta override this compensation that our brain came up with. We gotta move the notes bit forward. And that's the fix.

Perhaps another way to compensate this is to delay the audio of midi playback as well. But that's doing it all in the wrong way. We just have to move the notes milliseconds forward depending on our round trip latency. To make it even more easy. A new feature can be introduced same as the quantize feature. Just select the notes and 'override the latency'. (If the buffer size or audio driver gets changed the roundtrip latency also gets changed, so this feature should remember the latency with which the midi notes got recorded). If there is such a feature all we have to do is just select and apply. That will be really cool 

Slugbaby
I have the same problem that I think you have.  Whether it's because I play the keys slightly ahead of where I want to, or because of the latency, i've found a simple fix.
I highlight ALL the MIDI data in the track, and simply drag it all later (to where the first note SHOULD strike).  Then, the timing issue has been corrected, while the playing is still real and un-quantized.

yes thats what I do for now. Also you can note your total roundtrip latency and drag them exactly the no of req millisec to get more accurate fix.

sonarman1
 
You are right. When that is the case its essential to be recording with low latency. To me that's not really the issue. (Coz we have automatic brain compensation )  With 40-60milli sec latency or even more! I have no problem at all in playing down the stuffs I need. I guess no one will find that a problem. Coz while recording this we don't even notice an issue. Our brain compensates by itself by accurately playing the notes 40-60milli sec ahead. Pretty awesome really  It just happens automatically. This compensation our brain brilliantly does to override the latency goes wasted when the recorded midi is played back without latency. That's where we have the issue now. During playback we gotta override this compensation that our brain came up with. We gotta move the notes bit forward. And that's the fix. Perhaps another way to compensate this is to delay the audio of midi playback as well. But that's doing it all in the wrong way. We just have to move the notes milliseconds forward depending on our round trip latency. To make it even more easy. A new feature can be introduced same as the quantize feature. Just select the notes and 'override the latency'. (If the buffer size changes the roundtrip latency also changes, so this feature should remember the latency with which the midi notes got recorded). Just select and apply. It will be really cool 

 
Most musicians find it unpleasant - if not terribly difficult - to play live with more than about 25-30ms of total latency between the fingers and the audio reaching the ear. At a more typical RTL of 6-12ms (or less) with the input latency being at most half the total, this is really of no consequence.
 
What I keep coming back to is that your original post showed something much worse than this happening with MIDI recording relative to the timeline, quite apart from anything to do with audio latency. That should not be happening, and isn't something that should require any enhancement to the existing latency compensation functionality.
 
I think this thread has gotten off-track by going into audio latency.

Most musicians find it unpleasant - if not terribly difficult - to play live with more than about 25-30ms of total latency between the fingers and the audio reaching the ear. At a more typical RTL of 6-12ms (or less) with the input latency being at most half the total, this is really of no consequence.

Yes lesser than 12ms latency is Ideal

What I keep coming back to is that your original post showed something much worse than this happening with MIDI recording relative to the timeline, quite apart from anything to do with audio latency. That should not be happening, and isn't something that should require any enhancement to the existing latency compensation functionality.
 
I think this thread has gotten off-track by going into audio latency.

Let me check. Can someone tell me 1ms=?ticks. Or 1tick= ?ms. Might be useful.

At 120BPM. When tick per quarter note is set at 960. 

quarter note = 960ticks = 500msec

8th note = 480ticks = 250msec

16th note = 240 ticks = 125msec

Hope I am right. Will get back tomorrow. Also will try the IgnoreMIDIInTimeStamps=1 in TTSSEQ.INI

I have trouble with anything over 10ms latency. I can play but it feels sluggish. At 25ms or more it would so seriously affect my performance that I wouldn't feel content with whatever I laid down, because there would be no idea of timing during playing. I agree with Brundlefly that your initial picture points to a bigger technical problem. You never really answered the original questions (I think?), what hardware are you using and with which drivers?