I can confirm PRV CC visual bug:
a) Add Controller 11 value 64 (for example) at measure 2. You should see a "box" all the way right from the measure 2.
b) Zoom PRV all the way out with mouse on it's time line. It is like 200 measures for me, but I have low resolution monitor. At some point in no longer zoom out more.
c) using mouse in PRV time line, start scrolling to see next measures, let say 1 "screen" right.
 
Excepted result:
the box should still be there
What I see:
box disappear, also on measures which are covered when you start to scroll back.
 
----------------------------------------------------
But the value change is still used for play, checked with TenCrazy Track diag.
 
Note that on one existing project I think I could also reproduce the OP problem, CC 11 change from "far away" was not shown in Track diag. But I am not sure since after I have started from scratch, I could not reproduce that again. I think at the time I could reproduce it, I have manipulated MIDI clips, also with CC 11. So that can be somehow dependent from which way the track is modified between CC set time and the play start time. But I could not find the sequence yet.
 
EDIT: I have found what I have observed and that is not OP issue (or may be it is?). If there is no Note between "old" controller value and "new" controller value in selected region, old controller value is not transfered. I think Sonar tries to be smart and think "if there is no note which can be changed by effect, why should I bother to transmit the effect?". What is strange, is that "new" value is still transfered when looping for the begging of the looped area (where "old" had to be transmitted) and for its real place.

azslow3
EDIT: I have found what I have observed and that is not OP issue (or may be it is?). If there is no Note between "old" controller value and "new" controller value in selected region, old controller value is not transfered. I think Sonar tries to be smart and think "if there is no note which can be changed by effect, why should I bother to transmit the effect?". What is strange, is that "new" value is still transfered when looping for the begging of the looped area (where "old" had to be transmitted) and for its real place.

 
Not sure what you're saying here. Playback will play all events in order in a loop region, and all controllers will be processed regardless of there being notes in between. Searchback will only send the the most recent event of each kind found. There would be no value in processing more than one previous event of the same kind, as the most recent one always prevails in terms of the synth's response. In the case of searchback, it would be more work to process earlier events to no effect, and in the case of playback, it would be more work to filter out superfluous events that do no harm. Hence the difference.

brundlefly

azslow3
EDIT: I have found what I have observed and that is not OP issue (or may be it is?). If there is no Note between "old" controller value and "new" controller value in selected region, old controller value is not transfered. I think Sonar tries to be smart and think "if there is no note which can be changed by effect, why should I bother to transmit the effect?". What is strange, is that "new" value is still transfered when looping for the begging of the looped area (where "old" had to be transmitted) and for its real place.

Not sure what you're saying here. Playback will play all events in order in a loop region, and all controllers will be processed regardless of there being notes in between. Searchback will only send the the most recent event of each kind found. There would be no value in processing more than one previous event of the same kind, as the most recent one always prevails in terms of the synth's response. In the case of searchback, it would be more work to process earlier events to no effect, and in the case of playback, it would be more work to filter out superfluous events that do no harm. Hence the difference.

What I observe is different: searchback controller last value is not sent if there is no note inside the loop which it can affect.
 
For example, I had CC11 = 100 at measure 200, CC11 = 64 at measure 400 and Note (C4) at measures 350 and 401. If the loop is from measure 399 to measure 402, CC11 = 64 is used for the beginning of the loop as well (while technically speaking at measure 399 CC11 = 100 was still in effect). If I insert some note at measure 398 with length up to 400, at loop start (measure 399) CC11 = 100, while note is not sounded (Sonar has no "note search back").
 
I repeat, I do not think that is the problem OP observe, and strictly speaking it is not a problem at all (till synth is using CC alone to produce some sounds)  but that observation can be somehow related.

azslow3
 
What I observe is different: searchback controller last value is not sent if there is no note inside the loop which it can affect.

Hmmm... I'm not seeing that, and it's not clear from your description how you're determining that the controller isn't sent.
 
Going back to my test project with Sustain controllers at 1:001:00, and no MIDI until Measure 1001, this is what I did:
 
1. Loop the last four measures of empty space before the MIDI clips start.
2. Insert CC64=0 (pedal up) in the middle of the loop.
3. Start playback and echo live MIDI input from my controller through the track to a software or hardware synth.
 
When I do this, the synth response to the live echoed MIDI (note only) is sustained in the first two measure of the loop., and not in the second two measure as expected. And moreover, the searchback to the pedal down at 1:01:000 is re-executed every time the loop iterates so the first half always sustains as expected.
 
 
 

azslow3
What I observe is different: searchback controller last value is not sent if there is no note inside the loop which it can affect.
 

I don't think that's the case but I have just yesterday observed something similar to the OP (but did not have time to dig deeper yet).
 
So far I have set-up 4 projects in a similar manner - the first 3 work, the 4th has a searchback issue when playback (not rendering) is started late in the project.
 
All my projects contain at least 4 MIDI tracks for external FX changes (prg chg + CCs, but no MIDI notes at all). There are a patch changes for each track at 1:3:000 and numerous CCs to bypass, reactivate external gear etc. throughout the song. The first 3 songs that can be started anywhere working fine also contain patch changes later in the song, the 4th (troublesome, yet unfinished) only has patch changes at the beginning and when started close to the end (almost 4 min into the song), Sonar sends wrong (!) patch changes i.e. it dials totally different patches on the external gear (when played from beginning it all works fine) ...
 
So far I haven't considered this a problem of the searchback length but reading this thread it would make sense (but that's easy to test for me later on today by inserting the same patch change later in the song) ...

I'll try to give that a whirl tomorrow. OP had originally indicated message type and complexity didn't matter so I've kept it simple up to now. But if only one out of four of your projects is misbehaving, the odds aren't good that I'll be able to repro a problem.

This thread is not ready to be in the problem reports forum and I am moving it to the Sonar forum

Correct me if I'm wrong, but the problem seems to be that the OP wants to render only a portion of a project, have it accurately reproduce the results of MIDI controller data, but believes this is not possible.
 
I'll let others figure out whether it is or not, but at least one solution would be to render the entire file, split at the place where you want the rendered section to begin, and discard the rest.

Let's hope no one is using notes for keyswitches; no searchback for those.

bvideo
Let's hope no one is using notes for keyswitches; no searchback for those.

Yes, that's why I try to avoid keyswitches.      But that particular problem, afaik, is in every sequencer, not just Sonar.   The OP is about a real, frequent, problem, hit many times.     The notion of render all and cut might work -- though even a 'fast' bounce takes several minutes for a long set of tracks with a lot of data. 
 
That also doesn't solve the problem -- maybe I didn't say it clearly -- when you are attempting to work in a project somewhere other than at the beginning, you don't really want to start all playback from the beginning every time.  And so you get hit by this lookback problem IN PLAYBACK.  Nothing to do with render.