I don't know if the track's MIDI channel overriding the events' channels is a bug or design flaw (I hope Bob will find it out soon), but there's a VERY easy way to change the channels of all events in the track at once if that's what you want to do (and you can do it without bouncing clips). All you need to do is select the track and enter the desired channel number in Event Inspector's "Channel" field and hit Enter.
 
So, clips really shouldn't inherit the track's MIDI channel number when bounced (for the sake of us who heavily use multi-timbral synths and the Controller pane). I would say the "problem" is that the command also changes MIDI channels although its name only says "Bounce to Clip(s)" (I mentioned this before, didn't I?)   

icontakt
I don't know if the track's MIDI channel overriding the events' channels is a bug or design flaw.

I don't think it's either. The design is such that you can specify whether bouncing overrides the clip's MIDI data assignments, or not. That doesn't seem like a bug or a flaw, but a choice.
 
Now, you could argue the "flaw" is that you need to select None and that the reverse should be true - you would need to select a specific channel if you wanted the data to have consistent channel assignments. However, I think it's more likely that people will have a consistent channel assignment within a track, so it make sense to me that would be the "no click required" option, while maintaining a mix of channel assignments within a clip would be the "click required" option.
 
In any event Copper maintained that data is forced to a particular MIDI channel after a bounce, but that's not true. It can be forced to a MIDI channel after a bounce, but can also retain existing channel assignments after a bounce - your choice. I just don't understand why that's a problem...

icontakt
 
So, clips really shouldn't inherit the track's MIDI channel number when bounced (for the sake of us who heavily use multi-timbral synths and the Controller pane). I would say the "problem" is that the command also changes MIDI channels although its name only says "Bounce to Clip(s)" (I mentioned this before, didn't I?)   

To further support what anderton just wrote and also formally address the sake of us who heavily use multi-timbral synths:

• If we intend to drive just one voice of a multi-timbral synth from a track, then it is important we set the track's output channel to the channel number for that voice. Otherwise, when entering, copying, or moving events into this track from elsewhere, there is a chance the new events don't have the right channel, and won't get to the intended voice. We set it once and leave it. Low maintenance. Bounce is fine with this. 
• If we intend to drive several voices from one track, then it is essential we set the output channel to none. Otherwise, it is not possible to drive multiple voices from the track. Again, set it and leave it. Of course we must stay on top of the channel numbers every time we add events to the track. Kind of high maintenance compared with one voice per track. But bounce is perfect with this.

In either case, bounce works reasonably. No flaw no foul. Controller display, on the other hand, has flaws or bugs with or without bouncing. All of this is illustrated by preceding examples in this thread.

IMHO, the only flaw is the minimal documentation of the Bounce to Clips feature.
 
It would be helpful if the Reference Guide provided detail of what processing occurs when using Bounce to Clips for both audio and MIDI clips.  The Bouncing to clips section of the Guide makes no mention of any processing being applied to MIDI clips when bouncing.  There are 2 Notes that discuss slip-edited data and Render Bit Depth, as well as a mention that "All clip automation from the source clips is applied to the new clip".
 
- Ron
 

SquireBum
IMHO, the only flaw is the minimal documentation of the Bounce to Clips feature.
 
It would be helpful if the Reference Guide provided detail of what processing occurs when using Bounce to Clips for both audio and MIDI clips.  The Bouncing to clips section of the Guide makes no mention of any processing being applied to MIDI clips when bouncing.  There are 2 Notes that discuss slip-edited data and Render Bit Depth, as well as a mention that "All clip automation from the source clips is applied to the new clip".
 
- Ron
 

+1   Since the function itself seems to be working as intended and does offer the option to bounce with or without reassigning MIDI channel per object, all that's left is to improve the documentation to better describe what's happening.   This thread sure seems like a good head-start on that!
 

Hey, it's a great discussion. I love it. 
I'm sure Bakers are reading this, so let me explain why I think this is a bad design (if not a flaw or bug).
 
First, I think Sonar, while it's a full-featured and versatile daw, should be user-friendly (I hope everyone agrees). And, of the following three methods of creating a MIDI track, I think the majority of users use either of the first two methods:
 
Method 1. Record real-time using a hardware keyboard controller
Method 2. Step-record using a hardware keyboard controller or the new Virtual Controller
Method 3. Use prepared MIDI groove clips
 
When recording MIDI data (methods 1 & 2 above) to one of MIDI tracks that belong to a multi-channel synths like Kontakt, you DON'T have to change the output channel of your keyboard controller (just leave it Channel 1) or the Virtual Controller (just select "MIDI Omni") trying to make it match that of the C drop-down in the track, because the track's channel overrides the events' channels (this is a great feature, isn't it?) This means, the MIDI events recorded are most likely to have channel number "1" (try step-recording using Virtual Controller with "MIDI Omni" selected).
 
Now, imagine you have several (or more) tracks that all contain controller data and you're working on a synth's modulation data in the PRV Controller pane, with the Track view also visible. You need to bounce a few MIDI clips in this track (especially because Sonar doesn't offer the auto clip-merging recording mode), and if you do it, the modulation events suddenly disappear from the Controller lane (which new users or infrequent MIDI users will definitely find confusing, and it is NOT user-friendly).
 
Your argument is that the user can change the track’s MIDI channel to "None" before bouncing, but this step may or may not be necessary depending on which type of synth (single-channel or multi-channel) is assigned to that track. Users definitely wouldn't want to wonder like, "Did I use Kontakt or Nexus for this synth track?" every time before bouncing clips that contain controller events.
 
Of course, you can just use the Event Inspector's Channel field after bouncing the clips, but my point is that the program should NOT do what most users don't expect (or what the command's name doesn't say).
 
Hope it makes sense. 

icontakt
Hey, it's a great discussion. I love it. 
I'm sure Bakers are reading this, so let me explain why I think this is a bad design (if not a flaw or bug).

Sure thing!
 

icontakt
First, I think Sonar, while it's a full-featured and versatile daw, should be user-friendly (I hope everyone agrees). And, of the following three methods of creating a MIDI track, I think the majority of users use either of the first two methods:
 
Method 1. Record real-time using a hardware keyboard controller
Method 2. Step-record using a hardware keyboard controller or the new Virtual Controller
Method 3. Use prepared MIDI groove clips
 
When recording MIDI data (methods 1 & 2 above) to one of MIDI tracks that belong to a multi-channel synths like Kontakt, you DON'T have to change the output channel of your keyboard controller (just leave it Channel 1) or the Virtual Controller (just select "MIDI Omni") trying to make it match that of the C drop-down in the track, because the track's channel overrides the events' channels (this is a great feature, isn't it?) This means, the MIDI events recorded are most likely to have channel number "1" (try step-recording using Virtual Controller with "MIDI Omni" selected).
 

I use buttons on my controller to quickly change channel selection so I can direct Sonar to play or record different tracks (without touching Sonar's GUI), based on the input channel for each track. That's one particular way to exploit the versatility of Sonar. So events on my tracks are definitely not always 1. But let's say for those tracks I set the C drop-down accordingly so I shouldn't have any problems.
 

icontakt
Now, imagine you have several (or more) tracks that all contain controller data and you're working on a synth's modulation data in the PRV Controller pane, with the Track view also visible. You need to bounce a few MIDI clips in this track (especially because Sonar doesn't offer the auto clip-merging recording mode), and if you do it, the modulation events suddenly disappear from the Controller lane (which new users or infrequent MIDI users will definitely find confusing, and it is NOT user-friendly).
 

It would be a great thing to understand the scenario where modulation events disappear from the Controller lane. It certainly isn't friendly when they do that. If the events were recorded as you say on channel 1, and the C drop-down says channel 1, no channel numbers should change by a bounce, as discussed above. Have you found a bounce scenario that is different from the anderton(#14), bvideo(#12), and squirebum(#15) scenarios in the posts above?
 
On the other hand a flaw has been confirmed about displaying Controller lanes. And I believe that's what's really causing the problems here. And if so, that would not be the fault of bounce. The flaw with the Controller lane display is that it is divided up according to the channel numbers in the events, and does not respect the C dropdown. That's why bounce appears to mess up the controller lanes. Event channel numbers are changed by bounce from your default, or "don't care" channel '1' to the channel number of the track. So the controller display should be made to ignore the event channel #s because the user has obviously directed Sonar to send all events of the track on the chosen C dropdown channel.
 
That flaw also bothers me even without bouncing because I move or copy events among tracks that were recorded with various channels. So I'd like it fixed no matter what bounce is doing. If you reread my post#9 above, I explain this in slightly different terms.
 

icontakt
Your argument is that the user can change the track’s MIDI channel to "None" before bouncing, but this step may or may not be necessary depending on which type of synth (single-channel or multi-channel) is assigned to that track. Users definitely wouldn't want to wonder like, "Did I use Kontakt or Nexus for this synth track?" every time before bouncing clips that contain controller events.
 
 

My suggestion is not to change the MIDI channel C dropdown to none and back, but to set it and forget it, according to whether you want a multi-channel or single-channel track. This is a separate issue from single-channel vs multi-channel synth. I have been assuming that you and I and most people find it more convenient to have single-channel tracks, not multi-channel tracks (if that's not true for you, the discussion alters slightly). In that case, set the C dropdown to the channel number that drives the voice in the synth, and leave it that way. If the controller lane display would honor that, we might not be having such a long discussion.
 

icontakt
 
Of course, you can just use the Event Inspector's Channel field after bouncing the clips, but my point is that the program should NOT do what most users don't expect (or what the command's name doesn't say).
 
Hope it makes sense. 

It's most likely not necessary to change event channels unless purposely using multi-channel tracks. And as far as what people expect, I think they would expect never to have to worry about the channel numbers of events on any track where the output channel of the track has been set with the C dropdown. That should include displaying Controllers.

I've been thinking that the reason why the Controller pane in Sonar displays only one channel per lane is that there are users who want to edit data that way (by channel). It would certainly be nice to have an option to choose between displaying only one channel per lane and displaying all channels in one lane (to meet the needs of both types of users). But since we don't have that option (yet), it is IMO acceptable that the pane creates lanes per channel.
 
As for recording MIDI with a multi-channel/timbral synth, I think this is what the majority of users do:
1. Load the synth into the Track view.
2. Give each instrument in the synth a different MIDI channel.
3. Create multiple MIDI tracks and choose the corresponding MIDI channel number from the C drop-down for each track to play the right instrument in the synth.
4. Just record data by the method 1 or 2 I mentioned earlier, without worrying about what MIDI channel the device is sending.
 
IF this is what they actually do, then it is likely that all MIDI events in the project have the same channel number. And they want to be able to merge clips without having to wonder where the controller data that were there in front of their eyes have gone after they simply merged two clips to one.
 
The thing is, if you just want to change the events' channel number at once, you can easily do so by selecting the clips (or the track itself, or even Ctrl+A) and enter the desired channel number in the Event Inspector, but if you just want to merge clips together (without forcing the channel number to change), you have to select "None" from the C drop-down first, and figuring it out will take time for new users.

I can appreciate Tak's reasoning from the standpoint that Track parameters should not affect a bounced clip.  If other Track parameters affected a bounced clip, then should I expect the resulting volume of an audio clip to be lower when the track fader is lowered by 12 db prior to a clip bounce?
 
The problem with changing the behavior after it has been an accepted part of Sonar since at least version 8.5 is that now experienced users will be screaming from the rooftops about loss of a "feature".  This doesn't take into account the innumerable Problem Reports "Bounce to Clip won't change the MIDI channel". 
 
I think we all agree that the controller lanes should update after a bounce and this should definitely be addressed.

Submitted a feature request. 
 
Bounce to Clip(s) Special