Limit to controller look-back

Solution to this one would seem easy:  whatever the limitation to look-back is (time, ticks, bars, samples) ... make it an option to look-back all the way to 0. 

- Steps to reproduce?
- What controller number(s)?
- What synth(s)?
- How many measures?
- Does it matter how many other tracks are in the project?
 
 

I'm pretty sure it was discussed here already.

This is the Problem Reports forum. Discussion is not going to cut it. The idea is to give a reproducible recipe, have others confirm it if possible, and then enter a formal Problem Report based on that recipe.
 
Since none has been given, I tried to cook up my own:
 
I put MIDI clips in two tracks, one hardware synth (Aslesis QSR), and one soft synth (TruePianos) at measure 1001 (32 minutes at 125BPM). Then I went back and inserted CC64=127 sustain controllers at 1:01:000 in both tracks. I have Zero Controllers on Stop and Patch/Controller Searchback enabled. For good measure, I enabled input echo on the MIDI tracks and cycled my sustain pedal to ensure both synths got a CC64=0 before playback started.
 
I started and stopped playback several times both before at the beginning of and in the middle of the clips, and both synths played every note with sustain held throughout with Zero Controllers stopping the sustain on stop as expected.
 
As I suggested earlier, it appears to me that the lack of a controller shadow is a display issue only; the last controller value is still in force, and searchback seems to be working fine as well.
 
So we're back to square one, Gentlemen. I'll be happy to try and reproduce any detailed steps you care to submit.
 
P.S. Since William has mentioned Kontakt previously, I just tried the above with Alicia's Keys in Kontakt Player, and it behaved properly as well. I don't have the full Kontakt sampler.
 

Hold the phone. Looking back, I see you're talking about rendering, not playback. That makes me think the issue is that you're not including the controllers in the selection. Searchback only applies to playback. I think it would be a feature request to have Searchback include rendering the effect of non-note events that aren't included the selection.
 
EDIT: Cross-posted. I see the problem now. Call it a bug if you wish, but bouncing was never intended to include events that aren't selected.

Further -- Brundlefly, I have no idea if you are simply volunteering here, or representing CW -- but take what you said above:
 
Call it a bug if you wish, but bouncing was never intended to include events that aren't selected.
 
Now, imagine using an "Audible (slow) Bounce" --- do you think that look-back should not be used in this case?  Of course not -- look-back is and must be part of playback and of rendering.  
 

I really wish people would never post that way, dismissing and misdirecting.   Your comment makes it look like I haven't given a formula, but if you look up three comments or so it's there plain as day.   It applies to render and playback.   Can't be more clear than that.

williamcopper
I really wish people would never post that way, dismissing and misdirecting.   Your comment makes it look like I haven't given a formula, but if you look up three comments or so it's there plain as day.   It applies to render and playback.   Can't be more clear than that.

Your "formula" was very unclear. You never said you were bouncing a limited selection that didn't include the controller until after I figured it out myself. And you said searchback "doesn't work". I'm telling you it works for me on playback (and recording), no matter how far back the controller is. That's not misdirection; it's just a statement of fact of what I'm seeing.
 
Over and out.

williamcopper
Please satisfy yourself that in fact look-back IS CURRENTLY IN USE, ALWAYS.   For any kind of rendering. 

Okay one last response:
 
Please satisfy yourself that the Ref. Guide makes no mention of Searchback applying to offline rendering. It's a playback function.

Doubtful, but...  any chance the difference between your two results could be the version of SONAR used?
 

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.

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.
 
 
 

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.

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.

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.