+1, this seems to be exploding into something more complex than it should be. Consider a simple split... both sides of the boundary need to be consistent to the split material... MIDI ON/OFFs inserted with split MIDI, time signatures, automations, etc. The example of a "prompt jump" in a parameter on a split would place different values on each side of it, say 100bpm->110bpm... at the split point, the lead should have a tempo insertion at 100bpm at the end, and the tail get an insertion of 110bpm at its beginning. Basically, the left side of the split gets "end nodes" to everything crossing the split boundaries, and the right side gets "start nodes" inserted similarly.
 
If completely vertical, all things in the timeline would go with it by default (markers, etc.).

mettelus
+1, this seems to be exploding into something more complex than it should be. Consider a simple split... both sides of the boundary need to be consistent to the split material... MIDI ON/OFFs inserted with split MIDI, time signatures, automations, etc. The example of a "prompt jump" in a parameter on a split would place different values on each side of it, say 100bpm->110bpm... at the split point, the lead should have a tempo insertion at 100bpm at the end, and the tail get an insertion of 110bpm at its beginning. Basically, the left side of the split gets "end nodes" to everything crossing the split boundaries, and the right side gets "start nodes" inserted similarly.
 
If completely vertical, all things in the timeline would go with it by default (markers, etc.).

Yes, exactly!

You've explained in succinct terms the steps I carry out manually and explained in (too much) detail earlier. I don't think this sounds complex or out of the ordinary at all, and yet the workaround that I use at least is complex and extraordinary.

That's why this area is due a facelift.

I've been using Sonar / Cakewalk since it came on a floppy and ran on DOS. I love the software and know its ins and outs. And this rearrangement and deleting of measures could do with some modern love.

I noticed sometime around X1, and especially after take lanes were added, that adding time, and sometimes subtracting time, and cut and paste became a chore.  I have internalized the work arounds I've found so well, while thinking (for the last couple of years)... surely this is such a big impactful thing to so many people that Cake will fix it. 
 
And truth be told, every time a new update comes out, it's one of the first things I look for.
 
Here are my work arounds.
 
a. Never, ever, ever add time in the middle of a Melodyne clip. Must bounce track first.
 
b. Never, ever add time ahead of a melodyne clip. The data behind it, and the clip will get out of sync. Either bounce it, or to keep it an editable melody section, go into the melodyne editor, select all, and manually drag the data to where it needs to go.
 
c. When copying from and pasting into a take lane, never paste where I want it to end up directly. Instead, go to the right, past the last take lane for that track and paste it. Then, drag it in where I want it to end up.
 
d. Sometimes, despite best efforts, (c) results in take lanes arguing - it simply will not drag into place.
 
e. When copying and pasting across multiple tracks, do not depend on paste (insert) to move everything over the same amount. Some things will move correctly, some won't. (Yupper, everything is selected and nothing is locked...). The work around,. and thank goodness it often works, is to comply with (a)-(d) first, then add blank space in the tracks to exactly match the the time span needed, then paste it in as an overlay.
 
As I said, I have become so use to doing these work arounds that the time impact on my work flow is minimized. Still, I must admit, every time I have to go through this a little voice in the back of my head says when the %$%^& are they going to square this most basic of all functions away?
 
Rick
 
 
 
 
 
 
 
 
 

rickidoo
I noticed sometime around X1, and especially after take lanes were added, that adding time, and sometimes subtracting time, and cut and paste became a chore.  I have internalized the work arounds I've found so well, while thinking (for the last couple of years)... surely this is such a big impactful thing to so many people that Cake will fix it. 
 
And truth be told, every time a new update comes out, it's one of the first things I look for.
 
Here are my work arounds.
 
a. Never, ever, ever add time in the middle of a Melodyne clip. Must bounce track first.
 
b. Never, ever add time ahead of a melodyne clip. The data behind it, and the clip will get out of sync. Either bounce it, or to keep it an editable melody section, go into the melodyne editor, select all, and manually drag the data to where it needs to go.
 
c. When copying from and pasting into a take lane, never paste where I want it to end up directly. Instead, go to the right, past the last take lane for that track and paste it. Then, drag it in where I want it to end up.
 
d. Sometimes, despite best efforts, (c) results in take lanes arguing - it simply will not drag into place.
 
e. When copying and pasting across multiple tracks, do not depend on paste (insert) to move everything over the same amount. Some things will move correctly, some won't. (Yupper, everything is selected and nothing is locked...). The work around,. and thank goodness it often works, is to comply with (a)-(d) first, then add blank space in the tracks to exactly match the the time span needed, then paste it in as an overlay.
 
As I said, I have become so use to doing these work arounds that the time impact on my work flow is minimized. Still, I must admit, every time I have to go through this a little voice in the back of my head says when the %$%^& are they going to square this most basic of all functions away?
 
Rick
 

Wasn't the problem with adding new time around Melodyne clips fixed at some point?

Yes I agree with the more simple views. My way of describing my simplistic view is this... If I took the song before I removed a section and exported it to a stereo wav file. Now I just have a stereo song in a file that I can play.
 
If I were to take that wav file, split it at two places, remove the hole and slide the right clip back to the left clip. The result is exactly what I think sonar should give me if I deleted a "hole" in there.  
 
Seems very simple and logical to me.
 
There a few housecleaning chores that sonar would have to do to accomplish this. Any markers, tempo changes, whatever should be anchored to wherever they were in the song and move with the rest of it. If a midi note was cut in between a note on and a note off, then a new note on would be at the cut point (because in the song that note was ON at that point) and the note off should remain at the same place it was. So now the note is shortened. If you remove a section where the tempo is ramping, it should remove whatever piece of the ramp which will require re-positioning some things in the tempo map. But at the end it should play JUST like it would be if you cut the hole out of the rendered stereo wav file.
 
gabo

sharkeWasn't the problem with adding new time around Melodyne clips fixed at some point?

>>> PARTIALLY - I just did a test.  I was able to insert space before a melodyne clip successfully. But if I tried to cut time away before the melodyn clip, the clip physically moves, but the underlying data stays where it was. I did the test 3 times.
 
And, I can not insert a space if within the melodyn clip.
 
So, it really hasn't.  On the upside, I usually add time in more than remove it.....

gbowling
Yes I agree with the more simple views. My way of describing my simplistic view is this... If I took the song before I removed a section and exported it to a stereo wav file. Now I just have a stereo song in a file that I can play.
 
If I were to take that wav file, split it at two places, remove the hole and slide the right clip back to the left clip. The result is exactly what I think sonar should give me if I deleted a "hole" in there.  
 
Seems very simple and logical to me.
 
There a few housecleaning chores that sonar would have to do to accomplish this. Any markers, tempo changes, whatever should be anchored to wherever they were in the song and move with the rest of it. If a midi note was cut in between a note on and a note off, then a new note on would be at the cut point (because in the song that note was ON at that point) and the note off should remain at the same place it was. So now the note is shortened. If you remove a section where the tempo is ramping, it should remove whatever piece of the ramp which will require re-positioning some things in the tempo map. But at the end it should play JUST like it would be if you cut the hole out of the rendered stereo wav file.
 
gabo

 
+1     B.I.N.G.O. :-)
 
Feature Request here:  http://forum.cakewalk.com/FindPost/3376561 

http://forum.cakewalk.com/OK-what-did-I-do-wrong-this-time-m3376608.aspx
 
Looks like I missed this thread and started one on the same topic. 
 
Last night I opened the project in 8.5 and as expected it was not a problem at all to steal a section of the song and glue it to the intro. It was a straight forware operation. Same in Wave lab.  So I too think a bad thing happened with the introduction of the X series and for me it's a big deal. I don't expect my software to become worse to use. I won't change DAW's but everytime it happens I certainly think about it and my finger started twiching over my Cubase icon!

I think this thread (and countless others like it in the past) proves beyond doubt that regardless of the details of how it should be implemented, the desire for a workable, intelligent way to delete time from a project has a VERY strong consensus and would be a hugely popular feature if implemented. 
 
Personally I would like to see it appear as part of a new suite of song arranging features to facilitate the creative process. To me the mark of a great program is one which feels like an extension of your brain. Being able to say "move that section there, swap out this with this, get rid of this, try this here instead of here" and see it happen almost as the ideas come to us would be amazing. 

sharke
I think this thread (and countless others like it in the past) proves beyond doubt that regardless of the details of how it should be implemented, the desire for a workable, intelligent way to delete time from a project has a VERY strong consensus and would be a hugely popular feature if implemented. 

It seems the priorities are elsewhere.  Almost all of the significant changes recently have been oriented to mixing/ quality of sound as opposed to things important to composers.  At some point, one has to conclude that is the direction for the product and that Sonar is just not likely to be the best home for composers in the future.
 
I would appreciate any objective comparisons with other DAWs, concentrating on the capabilities that are important to composers (MIDI editing, notation, etc.)  It does seem that Presonus has been quite active lately.  Does anybody know how StudioOne deals with the time issues discussed on this thread?