[Implemented] - CWBRN-32278 Midi 'bounce to clips' changes midi channel

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.
 

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.

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.

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
)

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.

I hadn't actually indicated any preference one way or another for how it is currently being done - was just wondering if a bounce with Midi Output Channel set to none would preserve embedded midii channel numbers for the track, and if so suggested it might get the results you wanted.
 
Can you or someone, please indicate what the current documentation has to say on how it works for this situation?
 
If is is working as intended, as supported by documentation, then your desire to have it work differently would be best expressed as a feature request.  So, I am interested in knowing what the doc says about it.
 
Bob Bone
 

I moved this until it gets determined that the behavior deviates from the documentation (meaning it is a bug), and until it can get replicated by someone other than the OP.
 
As soon as both above get determined to be the case, then I will move it back over to problem reports forum.
 
I'm just trying to keep the problem reports forum clear of threads that aren't feature requests and not confirmed bugs.
 
I am in the middle of some stuff for about an hour, maybe 2, and I will try to look into whatever the documentation has to say about how Sonar SHOULD operate for this, if nobody has responded to my earlier request for someone to research that.
 
I will also try to keep an eye on this thread, and as indicated earlier will move it back to problem reports if replicated (confirmed) by anyone else and is shown to deviate from how the doc says it should work.
 
Bob Bone
 

Just ran through the steps provided in #12 by bvideo and can confirm the results:
 
1.  Setting the "C" output channel dropdown box to a specific channel causes all data to be converted to the selected channel.
2.  Setting the "C" output channel dropdown box to "None" leaves Notes and CC's to their original channels.
 
Ron

Anderton
The MIDI Channel field is a track-level command. The hierarchy is that a track affects clips, so a track command can override what happens on the clip level. If you choose not to have the track command override the clip, the clip data remains unchanged. 

 
I think there's track-level, clip-level and event-level. And, IMO, commands should work according to these levels. For example, record two clips in a MIDI track and change the track strip color to red and change the background colors of the two clips to blue and green respectively. If you bounce these two clips, the program can't decide which of the two clip background colors the new (bounced) clip should inherit, so it should inherit the track strip color (but what X3 and 2015 do is inherit the default clip background color black). As for bouncing two or more clips containing events of different MIDI channels, the program should NOT wonder what MIDI channel number the events in the new clip should inherit, because the events in the new clip can still have different MIDI channel numbers, whereas the clip can only have one clip background color. 
 
Edit: No, there's a mistake here. The track strip color is tied to the clip FOREGROUND color, so the bounced clip should indeed inherit the default black background color (just like it does in X3 and 2015).

icontakt
But, as I said, one clip can contain multiple MIDI channels (because they belong to events, not to the clip). So, Bounce to Clip really shouldn't change the MIDI channels.

It doesn't...as confirmed by three different people, unless we're not understanding the problem. All you have to do is set the MIDI Channel field to "None" prior to bouncing.

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

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!
 

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