• SONAR
  • Editing woes with take lanes - part 1 (p.2)
2013/12/21 11:45:08
Splat
So Charles it still seems to me that the solution from your perspective would be to disable drag and drop for clips/lanes because drag and drop is a useless distraction to the functionality? There is no use at all for it.

Wouldn't that be a worthwhile enhancement (maybe could be set in preferences by default so you still have the flexibility for some reason),
2013/12/21 12:02:56
Sylvan
Well, yeah. From my perspective, disabling the dragging and dropping of clips from Lane to Lane would be a good idea. It does seem useless as that is not the purpose of take lanes, but of Tracks.
2013/12/21 12:14:21
Splat
I will file this as an enhancement request. Maybe it will go somewhere...
2013/12/21 12:18:01
Sylvan
Cool. Thanks. Hopefully that would clear up some of the issues related to confusion going on out there.
2013/12/21 12:21:23
brundlefly
neirbod
As I drag a clip from one take lane to another, the other takes in the same time period disappear, or are slip edited down to  a tiny sliver.  This is repeatable in the sense that if it happens once, I can repeat it for the same clip over and over.  But, it does not happen for every clip.



I suppose I should really watch the video first, but this pretty well describes lanes working as designed. Same-lane clip overlaps are strictly prevented in SONAR (with the exception of a few bugs that still allow them to occur, but usually not by dragging). As a result, existing clips in the "drop zone" will be slip-edited automatically to eliminate the overlap.
 
My only complaint, which I've shared with the Bakers, is that this behavior can result in a clip getting slip-edited into oblivion - recoverable only by undo. And I think having Blend set in drag and drop preferences should either create a new lane if the clip is coming from another track or time range or actually merge the content of the clips together into a single clip (mostly a MIDI feature).
 
EDIT. Oops. Yes, I should 'a' watched the video first. That's definitely not WAD.  But I haven't seen it. My first suspicion would be that the project originated in an older version, and something was lost in translation to X3.
2013/12/21 14:09:38
neirbod
Sylvan
Well, yeah. From my perspective, disabling the dragging and dropping of clips from Lane to Lane would be a good idea. It does seem useless as that is not the purpose of take lanes, but of Tracks.



CakeAlexS
I will file this as an enhancement request. Maybe it will go somewhere...

 
It is not useless, at all.  Just because you don't use or need the feature does not mean it has no value!  I should point out that most of the time this feature works just fine.  But some combination of many takes and/or deleted takes seems to throw it off.  
 
Have you ever had 50 or more takes in a track?  This is not uncommon for something like background vocals, where you may have punch ins at 8 different places and you do 6-7 takes each.  There is no way to tell Sonar to "always start a new recording at take 1" so you end up with 50 or so non-overlapping clips in 50 lanes with a huge amount of wasted real estate that you need to work through. This makes it impossible to efficiently comp.  Ideally we'd have something similar to the old rebuild layers feature to clean things up, but given that does not exist in X3 one needs to do this manually.  It it is usually possible to drag clips around to consolidate into 7 takes, but there is apparently a bug that kicks in sometimes.  I simply ask that Sonar fix the bug.  I will submit a bug report, but thought I'd check here first to see if I could learn anything valuable.
 
This project was started in X3c, so not likely a problem with an older project not translating properly (but possible).
2013/12/21 14:12:05
Splat
neirbod
Sylvan
Well, yeah. From my perspective, disabling the dragging and dropping of clips from Lane to Lane would be a good idea. It does seem useless as that is not the purpose of take lanes, but of Tracks.




It is not useless, at all.  Just because you don't use or need the feature does not mean it has no value!  I should point out that most of the time this feature works just fine.  But some combination of many takes and/or deleted takes seems to throw it off.  
 
Have you ever had 50 or more takes in a track?  This is not uncommon for something like background vocals, where you may have punch ins at 8 different places and you do 6-7 takes each.  There is no way to tell Sonar to "always start a new recording at take 1" so you end up with a lot of takes and a huge amount of wasted real estate with 50 or so non-overlapping clips in 50 lanes. This makes it impossible to efficiently comp.  Ideally we'd have something similar to the old rebuild layers feature to clean things up, but given that does not exist in X3 one needs to do this manually.  It it is usually possible to drag clips around to consolidate into 7 takes, but there is apparently a bug that kicks in sometimes.  I simply ask that Sonar fix the bug.  I will submit a bug report, but thought I'd check here first to see if I could learn anything valuable.
 
This project was started in X3c, so not likely a problem with an older project not translating properly (but possible).




 
CakeAlexS
Wouldn't that be a worthwhile enhancement (maybe could be set in preferences by default so you still have the flexibility for some reason),

2013/12/21 15:08:49
brundlefly
neirbod
It it is usually possible to drag clips around to consolidate into 7 takes, but there is apparently a bug that kicks in sometimes.  I simply ask that Sonar fix the bug.  I will submit a bug report, but thought I'd check here first to see if I could learn anything valuable.
 



The key is getting the full sequence of events that leads to to the bug, preferably starting from scratch with a new project with as little content as necessary. I suspect it's significantly more difficult for the Bakers to diagnose a project that's already "broken" without knowing how it got there.
 
But I've also had the experience that an issue just seems to crop up spontaneously in well-developed project, and can't easily be reproduced in a new one.
2013/12/22 13:07:27
rontarrant
brundlefly
Oops. Yes, I should 'a' watched the video first. That's definitely not WAD.  But I haven't seen it. My first su****ion would be that the project originated in an older version, and something was lost in translation to X3.

If you're bringing a project in from an older version of Sonar, it might work best if you:
- make sure you've bounced any edited tracks,
- start a new project in X3, and
- drag-n-drop the 'associated files' of the bounced tracks into the new project.
 
I may be out in left field here, but I'm thinking this is going to be the best way to ensure X3 doesn't pick up on something (maybe something nasty or undecipherable) from the earlier version from which the project hales, so to speak.
 
Also, just so you know, I have successfully edited take lanes as if they were layers, BUT only after learning to think in the new 'take lane' way. Don't ask me what the difference is; I'd be stumped for an answer at this point.
 
2013/12/22 13:15:55
rontarrant
neirbod
No argument with anything written, but regarding the specific issue I noted in my OP can anyone confirm or show me how this is user error. This is seemingly a simple drag and drop move to clean up takes that appears to be buggy.

Oops! I meant to reply directly to this, but please see my previous post.
 
I'm not thinking it's user error, but it may be something in your project file that's confusing X3. With such massive rewrites, there's bound to be something (even an outlier) that's going to bring an incompatibility to light in an unexpected way.
© 2026 APG vNext Commercial Version 5.1

Use My Existing Forum Account

Use My Social Media Account