I just read your post akfunk, will have to try that out, thanks.
FWIW, I just spent some time color coding the “selected” bits that go into a comp before recording a new take. It looks like it might work ok here, at least based on the 1st few first look-see trial runs. No need to “protect” the comp as far as I can tell - even when the new take “rewrites” over the original comp, the original choices are easily identified by their different color, and the original comp can be relatively painlessly restored by clicking on those blue meanies.
The new take in its new lane shows up uncut, and when you do cut it, the cuts are extended up into all the previous takes on their lanes.I found that the cutting of the new take is not trivial - it’s pretty easy to have a veritable plethora of extraneous cuts on the original lanes, which just seems like an accident waiting to happen, at least on my computer.
It’s not so bad if the new take cut is far away from the original cuts made when working on the first comp. It was easy enough to just use the glue tool to delete the new cuts that had appeared on the “old” comp segments, and that was fine.
But, if I try to cut the new take in the same place/at the same point in time that the old ones were cut … I found it almost impossible to overlay the cuts precisely, and thus I wound up with multiple very narrow/short “slivers” in my old takes. [Edit: SNAP to events - no problems now
]
I’m hoping these will go away with x-fading, but I haven’t gotten that far yet.
Hope this helps someone down the line, and also if anyone has any suggestions re: this process, am I overlooking something important …? Also, especially for lining the cuts in the new take up at the exact same point in the track that the original cuts were made, I’d appreciate it! [Edit: SNAP to events - no problems now
]
Thanks -