Clips in a locked track move if Global Ripple is on and an earlier clip in another (unlocked) track is moved.
Can anyone reproduce this?
Right. I think this should be changed.
Thanks PG. I was asking myself if this was intentional, but since you can’t directly move the clips when the track is locked (you have to unlock the track first), I figured it was wrong that something else in the montage could move the clips without unlocking the track. That and the fact that is doesn’t happen when the clips are locked.
Right. This is not a minor issue to me. If I lock a clip, I expect to stay in place no matter what happens around it.
I encourage a speedy patch.
Just found it also seems to happen if you right-click to insert multiple files on another track (which is not locked) and “shift existing clips to the right” is selected. Then clips on the locked track move whether global ripple is on or not.
And in this case, locked clips are affected (not just locked tracks). Doing the same (insert multiple files with “shift existing” selected) before locked clips, on the same track or another track, the locked clips move.
And also in the case of locked clips (not just locked tracks), copy/paste of 2 or more files at once with global ripple on, moves locked clips. Strangely, copy/paste 1 file doesn’t move the locked clips I don’t think.
Additionally, as discussed in past threads, the locked state of a clip should follow the save of the montage. The way things have been For example…
- Open a montage with a clip which is locked
- Unlock the clip then close montage without saving
- Reopen montage and witness the clip is still unlocked!
NOT DESIRED BEHAVIOR
The clip should have remained locked (the saved state of the montage). That is how every other DAW I am aware of functions.
Actually, I agree with you WYCA, that the lock state should be the same as the last montage save. It was unexpected here when it wasn’t as saved, which is why I brought it up in the first place.
Also, from what I can tell, all of the behavior I’ve described here is reproducible in Wavelab 7 (clip locks) and Wavelab 8 (track lock and clip locks). I think these things should be fixed, but I also think someone would probably have noticed by now if this affected anything they had.
Oh, believe me, I have noticed!! 
I have lost revenue, worth many times the purchase price of WL, due to “sabotage” from this silly, undependable, non-saving lock behavior. I recall making these same arguments years ago on this forum.
I would be extremely pleased if a little 9.1.01 patch came out next month to make this right.
Sorry, but this type of remark always makes me chuckle. So after finding out this behaviour, you didn’t anticipate to the fact that locked tracks weren’t really locked, but kept on letting yourself be sabotaged to the extent of losing many times € 600,-. Right. 
That’s not how I read what WYCA said. I read it as, sabotage happened, found out how/why/what was exploited, lost money by having to fix, re-supply, or whatever else to make it right. But maybe I’m reading it wrong.
However, re-reading, because “sabotage” is in quotes, my apologies to both Arjan and WYCA because I was making the assumption that actual sabotage had occurred, exploiting this “bug/unexpected behavior” whatever you want to call it, which may not be the case. But I also don’t doubt that WYCA is expressing an honest appraisal of how this has affected their operation. Locks are one of the most important things to depend on working correctly. And it was stressful here when I first encountered the issue. That’s all. My apologies.
I was merely reacting to the ‘money lost because of XX software bug’ that people so easily use. And that ‘their bug’ needs to be repaired ASAP and before anything else. PG has already said in post 3 that it should be changed. No apoligies needed, Bob.
Thanks Arjan. Actually the fix in post 3 is about the other problem: that locked clips, and clips on locked tracks can be moved by other activity in the montage, without having to unlock them.
PG hasn’t said he’s going to change the lock state issue that WYCA was talking about in the post about his past problem, so that might still be up in the air (PG?). I would just say again that I now agree with WYCA that lock state should be as it was in the last saved montage only. That it shouldn’t change based on lock/unlock without save, as it does now. WYCA has said (and I can confirm with Cubase, Reaper, and Pro Tools) that that’s how it works in other DAWs: lock state is as it was in the last saved session only. And like I said, it was unexpected to find it otherwise in Wavelab, and rather alarming at the time.
Sorry, but this type of remark always makes me chuckle. [/quote]
Where there might be more than one engineer QC person working on a project one can imagine how this save behavior could possibly result in undesirable outcomes. WYCA most definitely know what they are doing.
so that might still be up in the air (PG?)
I confirm I plan to address the issues reported here.
Thanks PG. That’s great.