Comments

JohnnyRoy wrote on 12/22/2003, 6:41 AM
This doesn’t seem unique to 4.0e. I just tried it on 4.0d and got the same results. If I have a fade to black and shift the clips left the fade is maintained but if I shift the clips right, the fade is lost.

The other annoying bug (feature?) is that if I have three clips with a 1 second fade between each and I delete the middle clip, I now have a 2 second fade (i.e., Vegas adds them). This is never what I want to happen. Ripple edit in Vegas 4 is a lot better than it was in Vegas 3 but it still has its quirks. I keep it off unless I really need it. Perhaps Vegas 5 will get it right?

~jr
swarrine wrote on 12/22/2003, 11:19 PM
Dang, I think it is back to select and drag for me, especially if I have many clips...

How about it SonicEPM? Does this qualify as a bug for you as well?
SonyEPM wrote on 12/23/2003, 7:14 AM
Please provide a simple step-by-step description and then I can comment further.
Udi wrote on 12/23/2003, 12:00 PM
Create event A
Add a fade at the end.
Create event B after A (not overlapping)
Drag event A to the right - and release the mouse.
Both events moved, the fade at the end of A is gone.

Probably - as you move the first event, it overlap the second event and a cross-fade is created on the fly. This deletes the fade and replace it with the crossfade. When you release the mouse, event B is moved and the cross fade is deleted - leaving a no-faded event A.

Second issue (maybe not a real bug):
Create events A, B, C in sequence, with a 1 second crossfade.
Delete event B
Event A and C have a 2 second crossfade

This is a result of moving C event by the duration of B event. What we expect is that event C will be moved by the duration of B LESS the diration of the crossfade between B and C. I hope it is clear.

Udi
SonyEPM wrote on 12/23/2003, 12:56 PM
Thanks for the info- agreed, this is annoying.
swarrine wrote on 12/23/2003, 9:10 PM
SonyEPM-
I don't want to be a total jerk, but does this qualify as a bug? Or is it just annoying?

Bottom line, does this go on the fix it now list? Or do we have to wait for SV5?

Sorry for being rude, but in my opinion, the lack of ripple or a reliable ripple has been a major detractor to this program for years. I advocated change on the old Sonic/Cow boards and do so now - on the new boards.

If work is lost by the simple act of moving clips, it is not annoying, it is wrong and should be a top priority to be fixed.

If left uncorrected, users should be told of the issue and of the best available workaround.

Blunt, but that is the way I feel.

Thank you.
farss wrote on 12/23/2003, 9:30 PM
I'll add my voice to that now that i know it's not just me being incompetant. I'd also add the inconsistant nature of the split function, well it's not inconsistant, it's consistantly wrong.

Simple example from memory, take clip and split into three. Delete first section with ripple on, does what you expect. Starting again, delete second part, video gets deleted but not audio and third section slips down hiding audio from section two, but if section 2 was longer than section 3 end of section 2 audio is now sticking out of the end. If section 2 was shorter and then I insert black between what is now section 1 and 2 there's suddenly the audio from section 3 to accompany it.

Fortunately I mostly edit silent movies, don't know how the rest of you put up with this.

It's not just that this is time wasting it's that if you don't realise and therefore check everything very carefully you can send out stuff with minor glitches in it which is not good for anyone.
Udi wrote on 12/23/2003, 10:16 PM
In the delete case, the annoying part is that you MUST select both audio and video. Grouping does not work on delete.
So, when you select the second video clip, and delete - only the video is deleted and the audio remains, and ripple does it damage.
I whould like to have the delete effect the whole group when grouping is enabled.

Udi
farss wrote on 12/23/2003, 11:43 PM
Udi,
actually grouping does work, problem is when you split an event only the head stays grouped, not the tail. Tht's the root cause of the problem.
JohnnyRoy wrote on 12/24/2003, 4:41 AM
Just to give you a gauge of how annoying this is: I do a lot of slide shows with movement. I have 100’s of photos on the timeline (300-500) and I want a 1 second fade maintained between each event. Often, I want to delete photos from the slide show to tighten things up and end at a particular queue in the music and Ripple Edit is useless because if I delete a photo it makes the transition 2 seconds.

I would rate it slightly higher than annoying because I can’t think of a scenario where I would want the transition times added together. Sounds like undesirable behavior to me. (i.e., a bug) ;-) I realize the fix is not simple because the two transition times may be different. You would probably need a preference option to take the transition time of the incoming clip or outgoing clip. (heck, at that point you could add a third option to add them like it does now)

~jr
Udi wrote on 12/24/2003, 4:57 AM
Yes, grouping does work, but not for delete.

After you split, 2 groups are created, one for the head and one for the tail. So far - perfect. Actually, you select any event in the group and split it - the whole group is splited - exactly as expected. If you move one event, change length etc. - the whole group change. Any change you made on the TL will effect the whole group - with one exception - delete.

Regardless of split, you select the video event - and delete it - the audio is NOT deleted. You must select both video and audio and then delete.
If you that with auto ripple, the audio event is overlaid with another audio event. And it can cover it completely - and you will never know about it - untill you get funny soundes, orthe audio will pop a few days later when you move or change the audio tracks.

Udi

swarrine wrote on 12/29/2003, 8:31 PM
bump
HPV wrote on 12/29/2003, 8:46 PM
A simple workaround is to fade to another clip. I made a 2 second 7.5 IRE black and 100 IRE white dv clip from the media generator for just such use (plus I hate holes in my timeline). Renders (no render) faster than using the media generator for each project.

Craig H.
SonyEPM wrote on 12/30/2003, 7:28 AM
Swarrine's issue occurs when the right edge of event A becomes a crossfade with the left edge of event B and then ripple is invoked (via auto or with one of the post edit ripple F commands). If you drag event A so that its left edge goes past event B's left edge, the fade on event A remains after ripple. After lots of poking I think the above is the only place where this particular issue occurs. To get around this you could do a "select all to end" from event A, then move A (and evenything after it) and you should be fine.

This isn't a bug in the strict sense of the term but it is an inconvenient behavior I agree and we'll see what we can do about resolving it in a future version. Thanks for pointing it out.