Craig just to pin you down (sorry). Are you saying that you think Conley's steps isn't a bug , more of a misunderstanding with the way it works, and you are offering a workaround/better way?
 
Or it is a bug, and you are offering a workaround/better way?
.... as you are able to reproduce...
 
Cheers...

ack, I need to add a step 7 - Right click in the Track view after the area is selected for processing options. At this point, the entire clip is selected and I am not able to process the desired clip with lanes collapsed.

CakeAlexS
....more of a misunderstanding with the way it works...

Exactly. I'll give a more detailed report later when I'm at my main computer, but it's important to remember these are called Take lanes, not Edit lanes. You can do editing with them, and I'll describe how that works later. But frankly, just as there are more convenient ways to do takes than with standard audio tracks, there are more convenient ways to do editing than with take lanes. They are optimized for a specific purpose, which they do very well.

In my reported project, I was trying to edit the clips In the audio track lane, not take lanes,  and now I am not able to.
 
I just went through my recipe on a new project and it works as expected. Something between X3C and X3D has corrupted my project I originally reported in this thread that it does not behave this way. I believe I know how it is supposed to work and it has changed from X3C to X3D on my machine. I will see if I can post a project for you if you want.

I have the project loaded up on my FTP if anyone is interested in trying this out. I will PM you the file location if interested.
 
15 measures with 2 takes of audio.

Another thing I noticed, with many people reporting performance issues in X3D, I noticed some popping and clicking in playback of this project. I played the raw audio files outside of SONAR and they had no popping or clicking as SONAR X3D did. 

Conley,
 
I'm trying to follow your recipe but am not seeing a case where a comp clip is drawing on the track when lanes are collapsed.  However, if there's a situation where an edit operation is being blocked, we can look into it.
 
Thanks.
 
 

Sidestep...
 
Keith as you are here there are interesting points being made on all of these threads, I just thought I should point it out:
 
http://forum.cakewalk.com/I-still-dont-like-Take-Lanes-m2940872.aspx
http://forum.cakewalk.com/Editing-woes-with-take-lanes-part-1-m2953739.aspx
http://forum.cakewalk.com/I-posted-a-feature-requst-to-return-layers-as-well-as-lanes-m2954167.aspx
 
Thanks...

PM sent Keith, and Thanks for the post!
I reported later that my recipe does not repro on new projects in X3D. It appears that X3D corrupted this process in my bundle file I PM'd you about.

I suspect there is a misunderstanding of how the clips view displays data in X3 and the clips view editing paradigm rather than a bug.
 
X2 and earlier had a very simplistic representation of overlapping clips. Overlapping clips were drawing in order of creation or something like that *not* respecting whether they were audible or not. This made editing very non-intuitive.
In X3 we changed the drawing and editing tools to respect a WYSIWYH paradigm (what you see is what you hear). If you have a ton of overlapping clips but only one clip is audible, SONAR will favor displaying the audible clip. By far this is a far superior representation of the clips view because you are editing what is audible. Any non audible clips will NOT be drawing if they overlap with audible clips. i.e. there is a notion of "audible depth".
If you want to edit a muted clip that is obscured by an audible clip, the proper workflow is to open take lanes and edit them there. There is no other efficient way to edit overlapping data on a single track - its a paradigm that most other DAW's don't even allow.
You could move the clip that obscures the muted clip but that defeats the whole purpose IMO.
 
Hope this clarifies this somewhat...

Noel,

Can you look at the "woes" post i made and CakeAlexS shared in is most recent post (middle one)? Is this normal and expected behavior?