• Features & Ideas
  • [Implemented] - CWBRN-32278 Midi 'bounce to clips' changes midi channel (p.2)
2015/04/01 12:55:20
robert_e_bone
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
 
2015/04/01 14:42:05
bvideo
williamcopper
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. 


We seem to be getting different bounce results. I just tried with a freshly created midi track:
1. I recorded some notes that are natively recorded on channel 2, as verified in the event view.
2. Made a second copy on the same track
2. I set the output channel (the [c] widget in the track header) to 1
3. selected and bounced the original clip
All those channels became '1' as expected, and of course the copy is not affected and still has channel 2 notes, as seen in the event view.
Then:
4. Set the output channel to "none"
5. Selected both clips
6. bounced to clip
It made a single clip, but none of the channel numbers changed. In this mode, playing the track sends notes on both channel 1 and channel 2 according to the way the clips were created in steps 1-3 (tested with a multi-channel setup on a h/w synth). So Sonar bounces the way I like it.
 
Would you want to describe how you are trying the channel setting for your bounce results, just so we're talking about the same thing?
 
This still leaves open the inconvenient design flaw/bug in displaying multiple controller lanes on different channels even when the output channel is set.
 
By the way, changing the channel on selected notes is extremely easy using the event inspector in the control bar.
2015/04/01 20:55:12
robert_e_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
 
2015/04/01 22:46:57
Anderton
williamcopper
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.

 
I'm pretty sure it's pilot error again, assuming I understand your scenario correctly. I believe you are referring to clips in individual tracks (not take lanes), you are bouncing a single clip to itself, and you believe that doing so forces all the data in that clip to acquire the same channel stamp...yes?
 
When bounced, the channel assignment for notes will be forced to whatever output channel is specified in the track's MIDI Channel field. However if this field is set to None, all MIDI data retains any original channel assignments.
 
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.
 
To verify, create a clip. Draw four or five notes. Double-click on each one, and in the Note Properties dialog box that appears, assign each one to a different channel.
 
Set the track's MIDI Channel field to None. Note that the Bank field or Preset field can also indicate None, but they are irrelevant to what you want. The MIDI Channel field has to be set to None.
 
Bounce the clip, and you can verify that all the notes have retained their original channel assignments. Now change the MIDI Channel field to, say, 4 and bounce. All the notes will now be assigned to Channel 4.
 
Furthermore, controllers retain their channel assignments when bounced with the MIDI Channel field set to None. This holds true even if you have the same controller represented on multiple channels. For example if you have controller 7 messages on 5 different channels, they'll retain their channel identities after bouncing.
 
[If I misunderstand what you're saying and you expect to send clip data assigned to various channels over a specific MIDI channel (e.g., channel 2) and have them retain their identities - in other words, channel 2 carries data stamped as channel 5, channel 1, channel 8, or whatever - that simply is not possible according to the MIDI specification. Any piece of data can have only one channel assignment. You can't have a piece of MIDI data stamped as channel 5 go through a pipe called channel 2 and expect it to somehow be de-multiplexed back to channel 5 on the way out.]
 
 



2015/04/01 22:59:08
SquireBum
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
2015/04/02 01:18:20
Anderton
Not sure why this was moved to problem reports, unless three of us have totally misunderstood what the problem is. We've all been able to bounce MIDI clips without forcing the clip data to a particular channel.
2015/04/02 08:04:28
icontakt
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).
2015/04/02 08:26:10
icontakt
So, it's just like clip foreground colors. When two MIDI clips that both have a yellow foreground color are bounced to a single clip, the new clip inherits the track strip color. 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.
2015/04/02 08:41:58
Anderton
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.
2015/04/02 08:49:01
icontakt
It doesn't, only when None is selected.
Also, if track commands are supposed to override what happens on the clip level, I would say the clips should also take the track's name when bounced.
© 2024 APG vNext Commercial Version 5.1

Use My Existing Forum Account

Use My Social Media Account