Comping issue with latest update (2017.06)? Someone please confirm?

Similar issues noted. Speed comping = crash fest with the latest formal release for me. Almost the exact same workflow, but SONAR crashes when hitting <Enter> to select a highlighted clip. Not on every clip, but very consistent on the ones that do crash.
 
Closer inspection reveals a new quirk with clip "splinters". Appears to create a new "splinter" between two regions swipe-selected for comping. You can easily see this when using the <> arrow keys to change focus between to (left/right) adjacent clips in speed comping mode. It gets' stuck on the "splinter" and you have to hit the arrow key again to get to the adjacent region. Slip editing seems to make it worse or perhaps create the problem condition. Appears to confuse the logic used to determine focus for a selected clip. 
 
Multiple instances reported via the Cakewalk Problem Reporter. 
 
Rolling back provides a greater degree of usability. 
 

Thanks Jackson for confirming that. I've now rolled back on this update as it was quite unworkable for serious comping.

mmarton
rolling back to beta or May version?

Previous released (May) version. Can't afford to spend time on early releases. 

jpetersen
Splinters in one form or another have been an issue for a long time.

Yes they have. I do a lot of speed comping on vocal stacks and it's the one task that will regularly create problems. Sometimes pretty quickly, sometimes after a number of edits. I don't bother registering them with the CW Problem Reporter anymore.
 

jpetersen
Difficult to reproduce.

 
I hit the wall fairly consistently with gospel vocal stacks. The takes never line up which I imagine makes it hard to keep track of clip boundary priorities for slip editing. I can sometimes drag some of the clip edges simultaneously, but more often than not, a slip edit or resetting a clip boundary will be blocked by some minute splinter. Initially wondered if it had something to do with the Undo history, as it never crashes right away (until this last release). Seems to be a cumulative issue that reduces stability the more you do it and maybe related to how fast you execute edits on 10-15 takes. Like it can't keep up with all the states and something falls out of queue.
 
If I need to get something done without crashing, I have to "clean up" the takes by selecting and deleting -all- of the splinters. Hardly efficient but a bit more robust. 
...
IIRC, an earlier release was tagged as "Part 1" of speed comping. Given the recent work on potentially related tasks, Ripple Edit, Melodyne, etc. guessing they have more work to do for a "Part 2". 
 
Seems to be a challenging task but have to think the dev team has a good handle on the use case. Perhaps a potential preferred solution might look like ...
1. "Auto healing" of splinters (perhaps defined by IF < maximum clip width THEN merge with the closest clip?)
2. "Auto delete" splinters (IF < maximum splinter clip width THEN delete )
After all, -why- do they even exist? Which might be addressed with 
3. A zone setting for the Smart Tool when selecting/creating clip sections in take lanes. 
4. A configurable Smart Tool with handy features for editing clips in speed comping mode. 

Gosh I always blamed myself for not keeping all the edits fresh in my head as I went. Don't think I ever saw 9 in one spot though. Not comping either.
 

https://www.youtube.com/watch?v=4nHOmGPeVc8&edit=vd

It happens to me while recording this video.

Yes can confirm it here.
 
I rolled back to May and no issue.  Something about the crossfades in June it seems...when you press enter it creates a crossfade "box" but doesn't delete the previous one.