pick any MIDI clip you have in your project, Apply trimming. Resize it, dragging the left edger either to the left or right, and now enter any Start point value of the clip in Inspector. Where the clip get moved? Now drag the left edge back to its original point and you will see, that the original left edge of the clip is at the time of Start point value. Not the edge of the resized clip.

While I have to agree this is incorrect behavior based on the way 8.5.3 worked. I think it's asking for trouble to have clip boundaries not correspond to actual MIDI event start and end times, except when using Groove clips, which are designed to work this way (and still do in X1).


If you want regular MIDI clips to maintain their relationship of MIDI to measure and beat boundaries, just use Move By instead of Move To when dragging, and don't touch the beat/tick values when manually editing the start times in the Inspector.


Or you can convert them to groove clips after setting the boundaries where you want them.

Thanks for the tip Brundlefly, but it is still a workaround. I do not like workarounds. Workarounds are for software that are free... :)

I hope CW will fix this.

Why do you think MIDI clip boundaries should correspond to actual MIDI event start and end times? The problem here is, that Sonar recognizes the wrong boundary - the one which is not visible because the clip has been resized, which means it is a new clip, right? :)

Another workaround to this is to Apply trimming to the resized clip or Bounce it to a clip. But, you know, see my first sentence :).

rainmaker1011

rbowser


I confess not totally following what you're doing, and part of that might be that I've never typed in in the start time field - I just grab a clip and move it to where I want, often with the grid off.  In the video I see you dragging the clip out longer at the top for some reason - why are you doing that?  That's just adding blank time to your clip--.

RB

Hi Randy,

I was dragging the clip out longer just to illustrate the problem. You can try it by dragging it shorter, the outcome will be the same. I use Start time filed when I want to move a clip to an exact time, lets say 52:04:268  because of some reason. And this way is the quickest and the most precise. But, not working in X1b.  

Hi, Marek - Thanks for the reply.  Interesting thread you have going - it's about something I have literally never thought about or dealt with. 

Hmmm. - Everyone has their preferred ways of working, so even though this sounds argumentative, I just wanted to say that I've done many very complex MIDI projects and have never done anything but grab and move clips when needed.  It's extremely fast and easy, I can't imagine how it would be more efficient to stop and deal with typing numbers--But it's hard to imagine working in a way we haven't, so I just don't know what I'm missing. 

But I've also never had problems getting clips to be exactly where I want them.  I work primarily in the PRV, with the current track in the TV visible above it.  I can drag clips as needed up there, doing the deeper editing in PRV where I can also easily see if a clip is sitting where it needs to.

And so on.  - I can't tell for sure if what you're talking about is a glitch or not.  It's all perplexing to me.  Hope you get a method going that works for you, and that you communicate with Cakewalk about what you're seeing - maybe they can either help explain, or acknowledge a bug.

Randy B.

The problem here is, that Sonar recognizes the wrong boundary - the one which is not visible because the clip has been resized, which means it is a new clip, right? :)

 
I guess the argument could be that since you have the ability to shrink and grow clips at leasure, there must be a stable starting and ending point that doesn't reflect changes that can be made on the fly.  Bouncing isn't a work around, it just establishes (cements) the boundaries.
 
Of course, this is only my supposition!
 
Brian

Here's something I didn't know about sliding clips in Sonar. May or may not be relevant to the OP but hope it helps in some way.

http://www.youtube.com/wa...vA&feature=related

This was talked about alead in great length. I can't remember who started the thread, or even the out come. But it has something to do with Sonar's ability to remember where a clip was. Reason being for undo type of stuff. But you can *Apply Trimming" and it will work the way you want. But it's not a work around. That's the way it's designed.

I wish I could remember the thread so I could point you to it. But I don't think this is a bug.

All this debate when the answer is simple (if only CW would learn) - JUST LEAVE IT WORKING LIKE IT USED TO IN 8.5.3!  (You used to be able to right click, bring up the clip properties and type in the start value you desire.)
I know eggs had to be broken to make the omelette that is Sonar X1 but I've come to the conclusion that a whole truckload was sacrificed... 

rainmaker1011
Why do you think MIDI clip boundaries should correspond to actual MIDI event start and end times?

'cause I'm old-school.

  Got the same Problem in a different way. I want to record Midi, that always fits into the loop-borders. Means if the Loop has 4 bars from start point 1.0.0 to 5.0.0, I want my clip to be the same lenght, even if I only record one single note. The Point of it is, that this seems to me the easiest way to creat grooveclips. I dont want to stretch or move a clip. I only want to record the clip, transfer it to a grooveclip and copy it in an easy way.

Well yours is easy to solve - just set your punch in/out points to correspond to your loop points.

Nothing outside of that will be recorded.