Oh, this thread is now in the Feature & Ideas forum.
Hmm......I think the forum host could have waited a bit until the OP received a reply from support.
The behavior in question is now highly likely 'as intended,' though.

icontakt
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).
 

Sound sensible, but the controller pane should use the track's assigned channel as the "one channel".

icontakt
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.
 

Fix the controller display so it works for all users, not just the "I only use channel 1" users. Why would anyone want to display multiple controller lanes for a track that has the track output channel lane set to a number?

icontakt
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 get the impression you're not addressing what I've said about the controller lane display being wrong.

SquireBum
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.

Rather than agreeing with how you said it, I would state the interaction between 'bounce' and 'controller lane display' this way: for tracks where the channel has been set to a number, the displayed controller lanes should not be affected by a bounce (or any other change in event channel numbers).
 
More generally, I'm saying the controller lane display should automatically treat all events as though they have the channel number associated with the track. The debate about what bounce does or should do is misleading, and is only raging because of what the controller lane display is doing wrong.

I understand your point, and I don't think I opposed to the idea of improving the controller display. I was only saying that Bounce to Clip should just do what its name says regardless of the track's channel (at least until the Controller lane display is improved, or fixed, which I thought would take longer or would affect some users negatively) because the current Bounce to Clip behavior could really confuse new/inexperienced Sonar users. If the Controller lane display could be improved and everyone could be happy, that would be the best solution, of course.

Did Copper ever realize you don't always have to force MIDI events to the same channel?

Craig,
Copper and others, including me, are bothered by the controller lane display. It's because of that there is a genuine need to force events in a track to be the same channel. So bounce's current behavior causes pain for people who enter or edit events using some channel other than the track's channel, given the controller lane display's current behavior. Yes, there are unpleasant workarounds, like manually forcing all events back to your favorite channel after a bounce, or changing your channel setting to none before a bounce and changing it back after.
 
Beyond that, we have various opinions on what bounce should and shouldn't do based on what we think "bounce" means. If it weren't for the controller lane display I wouldn't worry much about what bounce does or doesn't do. I only slightly prefer it continues to work as always. On the other hand, I run into controller lane display issues even without using bounce, so that fix is where my priority would be.

Distilling everything here, and bringing in some suggestions from other threads, I would support something like the following set of changes to the PRV and related functions:
 
1. Don't apply forced MIDI channel to events on Bounce to Clip(s); yes, it's been that way for a long time, but it wasn't at one time, and it is technically inconsistent.
 
* A separate "Apply Forced MIDI Channel to Events" command can be added if necessary, though Process > Find/Change suffices.
 
2. Make controller lanes honor forced MIDI channels.
 
3. Provide the following mutually exclusive controller lane display options:
 
- "Show lanes for All tracks"
- "Show lanes only for Visible tracks" (i.e. the Show/Hide button is enabled)
- "Show lanes only for Active track"
 
* Note that changing which tracks are "picked" to be shown in the PRV would still refresh the controller lanes, but it would honor the chosen display option so you'd only potentially see lanes added when using either of the first two options, and "Hiding" newly added tracks would automatically zap their lanes with the second option.
 
4. Make controller lane heights independently adjustable.
 
5. Provide an auto-zoom function for controller lane height.
 
6. Make the controller pane scrollable.
 
 

icontakt
Oh, this thread is now in the Feature & Ideas forum.
Hmm......I think the forum host could have waited a bit until the OP received a reply from support.
The behavior in question is now highly likely 'as intended,' though.

Yeah - the thread has bounced around - and I don't like doing that.  If indeed, however unlikely, that Cakewalk indicates it is actually an error, then it can get moved back into Problem Reports.
 
There were quite a few posts getting generated in the thread, and I wanted to try to keep that problem reports forum as clean as possible, so maximize any time spent by Cakewalk folks pulling things that are known to need the attention of the developers.  I certainly did not mean to confuse anyone - just trying to protect an exceptionally precious resource - the developers time.
 
Anyone who looks in problem reports will see the link here, so other than the thread being bounced around more than anybody would have liked, I think folks will be able to find it here.
 
I apologize to anyone for any disruption I may have caused.  I'll keep working on being better at things :)
 
Bob Bone
 

I would like to add one additional suggestion for consideration to brundlefly's summary in #37:
 
7.  Add an option in the PRV to only display a single MIDI data lane.

• The option could be added to the PRV Display menu or the Controllers menu.
• The default data type for the single lane could be Velocity.
• The data type drop down list to the left of the lane would be used to select which existing data type to display.
• The "+" button would still be used to add additional lanes for existing or new data types if desired.

The functionality is similar to Hiding the Controller Pane, but the user would have the convenience of editing data in a lane rather than in the Note Pane.
 
Rationale:  Currently Sonar automatically creates a separate MIDI data lane for each unique data type that is present in the selected track(s).  While this behavior may be useful to view all controllers that exist on a track, it may present more lanes than are useful to edit.  The user is forced to manually remove all undesired data lanes with the "-" button.  Closing and re-opening the PRV requires the user to repeat the manual data lane removal.
 
Thanks,
Ron

News to me is I can't change the midi channel of controller events with the event inspector. I didn't know it's only a note inspector.