williamcopper
From Kontakt 5 Reference manual:    "Sampler Controls: MIDI" -- "Sets the MIDI port and channel this Group will respond to."        IE:   A channel can trigger specific sounds in an instrument.    Drum maps are obvious candidates, but also string library articulations, legato transitions, many possible uses. 

But all that works only in case you are not forcing MIDI channel. And in this case bounce is not modifying event.
 
In case "force channel" is set, there is no different either the clip is bounced with modification or not. Even when your events have channel information, it will be changed before the event can be processed by VST.

azslow3
After carefully reading all posts, I still do not understand for what event channel information is good in case it is in the track with output channel set

The root of the problem is that lanes in the Controller pane of the PRV are differentiated by event channels as well as controller types and do not recognize the forced output channel setting.
 
Since Bounce to Clip(s) applies the forced output channel to the events, if you do a lot of bouncing to clips, and subsequent copying of events between tracks, you can end up with the same controller type using several different channels on the same track. The forced output channel takes care of ensuring playback is all on one channel, but when you open that track in the PRV, it might have multiple lanes for the same controller type copied from other tracks. This can be confusing and problematic in terms of the number and size of controller lanes that get generated/re-generated when the PRV is refreshed by changing track selections, especially when you have many tracks with many controller types showing in the PRV at once.

Well said, brundlefly.   I'd just add:  the controller BY CHANNEL lanes proliferate so quickly in even a relatively small project, that the PRV Controller Pane is VIVIDLY and OBVIOUSLY bad: you see 10-20 or more "lines" - straight lines, with no information and no controllers visible.  Absolutely useless and awkward to fix (one at a time, while the screen jumps each time you fix ONE of the 10-20 or more lines.)

I completely agree with the request to make the Controller pane better. But it is different from the original topic subject.
 
For my (noob) tasks, I would like either:

• changing channel during bounce is also applied the same way on copy. So in case let say I copy clip with channel 2 to the track with "C1", everything is converted to channel 1 during pasting. Sure, in case of "C None", there should be no changes (easy to implement, just hook inside paste subroutine)
• or pane just combine all channels when track channel is fixed (harder to implement, requires logic and GUI part reworked).

For the mean time, I think there is a workaround: insert FX which force channel fixing the same way as SONAR does and keep "C None". That way the channel is converted on the fly while bounce is not converting events. I have googled at least once such plug-in, but I have not tested it yet...
 
I have long time plan to write such DX myself and make the channel number as automation parameter. That creates a possibility to control articulations (in IK MP for example) live (using my CS plug-in...) without external channel "gymnastic" and record it as a track automation. Simple to write, but I have not found time yet.

azslow3
For the mean time, I think there is a workaround: insert FX which force channel fixing the same way as SONAR does and keep "C None".

In addition to ensuring that recorded MIDI events are sent with the correct channel information, the forced MIDI channel tells SONAR what channel to use when generating messages from MIDI track controls and automation envelopes for Volume, Pan, Bank, Patch, etc. I could be wrong, but I don't think those messages get processed by MFX, so you're going to lose that linkage. And those messages are sent on channel 1 by default when no channel is specified, so you'd have to avoid using that channel of a multitimbral synth.

Bank/Patch change can be inserted explicitly. You are right, TrackDiag does not show them.
 
At the same time, track automations are detected by TrackDiag (applied before FX???), so MFX probably can change the channel.
 
In total, workarounds are rarely perfect...
 

Doing some light reading: Sonar Reference Guide, page 1346: 
 
You can display notes on the fretboard based on the note event's MIDI channel.  (Do not confuse this with the Track MIDI Channel).  A single track can hold events on many different MIDI channels. 
 
I believe this confirms: the OP is about a BUG, not a feature request. 
 
 

williamcopper
You can display notes on the fretboard based on the note event's MIDI channel.  (Do not confuse this with the Track MIDI Channel).  A single track can hold events on many different MIDI channels.

Is see nothing about bouncing or changing the MIDI channel in events in this statements.
 

I believe this confirms: the OP is about a BUG, not a feature request.

A bug is something which does not work as expected. All other users has confirmed that while some improvements in that part of SONAR are more then welcome, there is nothing unexpected in the way it works now.

Also, if a MIDI track in previous versions of SONAR had a forced channel assignment, that channel would be applied to all channelized MIDI events when bouncing MIDI clips or saving a Format 1 Standard MIDI file. By default, SONAR will no longer re-channelize MIDI events during bounce operations. However, you can override the default behavior by adding the following line to the [WinCake] section of the Cakewalk.ini file:
[WinCake]

RechannelMIDI=1
1 = Re-channelize MIDI events
0 = Do not re-channelize MIDI events when bouncing MIDI data
 

 
The above is from the Dorchester release note. I think this thread contributed highly to the change. Now we're all happy (about bouncing MIDI).