Have been trying to figure out why the proliferation of controllers in PRV controller panel ... as I've complained before, you have to close one line per controller per track PER CHANNEL.   

Finally tracked down one source of the proliferation:  Bounce to Clips ignores channel setting in the midi data and changes all controllers affected to be set to the midi output channel of the track.    They are different things, so this is not good.  
 
While for many purposes the channel number in a midi stream is ignored, it can be useful (each event, note, controller, pitch bend, etc, has a channel number field).    The 'channel', same name, different thing, that carries a stream of data to an instrument, VST or otherwise, applies to everything in the track, regardless of the channel number on each midi event.
 
This is a design flaw, or bug.

Procedure:     Load a vst instrument that can accept multiple midi streams (channels).   I use Kontakt 5.   Set up two midi tracks, output to the VSTi, midi channel 1 and 2,    Load two patches into the VSTi, one on the first channel, a different one on the second channel.  
 
Open PRV, create a note in the first track.   That makes a "midi clip" containing one note.   By default, the note event will be midi channel 1.   Close PRV
Open PRV for the other track, create a note.   That makes a midi clip containing one note.    By default the note event will also be midi channel 1.    (This is midi channel 2, but whatever ... the event channel does not matter for most purposes). 
 
Add a controller.   Midi event channel 1.  
 
Select all midi data, Now use 'bounce to clips'  -- suddenly all the midi events on track 2 are set to channel 2.  
 
That's untroubling when you are working with 2 tracks, but how about 40-50 tracks, running to multiple VSTs?   Each will necessarily use a track-based midi channel, but the EVENTS on the track need not and should not have that number as their channel number.     Do a little copying, pasting, and the channel numbers proliferate.   Bounce to clips occasionally, then keep working: the channel numbers keep proliferating.     
 
And THEN you get the wild mess that drives crazy anyone trying to use the PRV controller pane --- one line per controller PER MIDI CHANNEL IN THE EVENT per track.     For a medium sized project, the controller pane is simply unusable, it is a mess of lines, too small to even close them one by one by one by one by one by one by one by one by one by one.
 

btw fixing this bug will be a good thing, but NOT enough to fix the controller pane problem.  Even at one controller per track (ignoring channel), i still never want to see a CC10 (Pan) lane or CC7 (volume lane) and usually not a pitch bend lane or after touch lane.

Haven't read the above posts, but the issue described in the thread title is a workflow killer for me (because it creates additional lanes in the Controller pane). Voted.

Personally, I've always liked this feature as an easy way to isolate like controller types on several tracks to their own lanes all at once. It's quite easy to go back and forth between the two modes by selecting some or all tracks and bouncing to clips to apply forced MIDI channels or Process > Find/Change to change everything back to channel 1.
 
Rather than changing the way bounce to clips applies forced MIDI channel, I'd prefer to see a "Re-use Lanes" or "Shared Lanes" mode for the Controller pane where it would show, for example, Modulation controllers in the Modulation lane for the active track, regardless of what channel they'e on. Add an option to "Show Controllers on Active Track Only" like the option for velocity, and you'd be in business.

brundlefly
It's quite easy to go back and forth between the two modes by selecting some or all tracks and bouncing to clips to apply forced MIDI channels or Process > Find/Change to change everything back to channel 1.

 
Yes, that's what I always have to do after bouncing MIDI clips. In my opinion, "Bounce to Clip(s)" should just bounce clips to a clip and do nothing else. If it also must reset MIDI channels, it should be called "Bounce to Clip(s) and Reset MIDI channel(s)."
 
"Show Controllers on Active Track Only" would be really helpful.

Question - and a commendation - the commendation is for williamcopper, the initial post for this thread was really well laid out - with the steps to recreate.  Thanks - I think posting an issue with that level of clarity and detail would make it easy for me to work through, if I were a Sonar developer. (I was a programmer for forever on mainframes in the non-Sonar corporate world, however).
 
OK - so the question is about the midi channel conversion - I would think the bounce wouldn't change the midi channel on event data for that track, if there were no midi channel assigned to the midi track's Output Midi Channel parameter) right below the FX bin.
 
So - will Sonar in its current release, leave any midi channels found in that track's midi data, when it bounces, IF right before the bounce any value for the Output Midi Channel is removed?
 
(after the bounce, whatever was there could be put back to whatever it was set to prior to being removed ahead of the bounce).
 
Just wondering if the above would give you a way to preserve those embedded midi channel values post-bounce.
 
Bob Bone
 

Bounce to clips on a track that has had its midi controller changed to None uses the original setting for midi channel.
 
Robert, you might like the way it works, but it is not right, and getting specific channels, or the channel number for a selected group of events, set to specific values should be done in another way, either the Process Find/Change, or the very simple CAL program I use:
 
(do
   (int new_chan 1)
   (int i 0)
   (getInt new_chan "New Midi Channel for selected events: " 1 16)
   (-= new_chan 1 ) ; sonar shows channel 0 as channel 1 and 15 as 16 so adjust
   (forEachEvent
        (do
               (= Event.Chan new_chan )
               (++ i)  ; count the change, this step could be eliminated if you don't care
        )
   )
   (pause "Adjusted " i "channel events." )  ; this step could be eliminated if you don't care
)

As a general rule, a function should do what it says it does, and not other things (like changing channel numbers for events to an unrelated track channel number for communication with an instrument).

If bouncing preserves midi channels when the Chn widget (output channel, [c]) says none, and normalizes midi channels when Chn gives a channel number, I Like It, So It Is Right(tm). I think of bouncing as a normalizing function that consolidates data, including envelopes, fades, fx regions, and effects associated with the clips. No clip-level processing is needed to play the data of a freshly bounced clip.
 
It does make sense to set the [c] widget to a channel when the intention is to send all events to the same voice, even though VSTis often don't require it. Since I often use h/w synths, I find it much more convenient than trying to keep the individual event channels right, especially when I might move or copy clips to different tracks, and wind up with multiple channels in events on a track. I agree it would be a pain to have to view multiple controller lanes when my intention is they all go to one voice.
 
In my setting, I have MIDI data arriving from multiple channels, due to the way I use channel number to sort data from my controller keyboard into different tracks. If I copy or drag clips or events from one track to another, tracks wind up with multiple channels in the data. Not on purpose. Setting the output channel on each track is my normal way to compensate for this inadvertent proliferation of channels.
 
There is another discussion entirely about how events are displayed. I have potentially the same data display issue that William Copper has, but for different reasons. I'd like it if controller lanes were displayed according to, again, the Chn setting in the track. If I'm forcing an output channel, differently-channeled controller events should not be displayed in different lanes. ILISIIR or maybe ILSR for short. If I were deliberately using controllers for multiple channels in a track, setting the Chn widget to none, I might prefer to be able to view them separately. But then again, purposely using multiple channels in a track requires a special kind of fortitude.
 
The "viewing multiple tracks in prv view" discussion is a good focal point for discussing whether controller events with different channels ought to show in different lanes. If tracks configured with different midi channels are showing at once in the PRV, then it's obvious that the intention is to show multiple instruments. In that case, is it really a good idea to show all like events in one lane? It seems to need an option, as the one brundlefly said, or maybe even a separate per channel vs combined controller display option. The single-track multiple-channel-on-purpose inline PRV case might benefit as well.
 
So my proposed feature request would be to honor the track's selected output channel not only in bouncing but in displaying controller data.

Interesting point of view.  A couple of observations: no, to your first "if" ... the individual channels are NOT preserved when bouncing to clip, regardless of the setting to none or not.   As far as I can tell, there is no possible way to preserve intentional channel choices and use bounce to clip.    I could imagine someone wanting to preserve individual CLIPS and set all channels to the same number ... my CAL code above does that; and someone else, like me, wanting to preserve individual CHANNEL NUMBERS and get all midi clips bounced into one larger unit.   So:  I'd still say it is two valid functions, and one operation should not try to do both.