Quantize to frames is sometimes ignored in V4.0b

elCutty wrote on 5/5/2003, 9:57 AM

With a 'low resolution' in the timeline trimming an event with the 4/6 Num-keys sometimes ends up with an event edge not on a frame boundary (PAL project). In auto ripple mode an 'interframe' transition is automatically generated between those two events. This causes the preview of a time loop on this event to show the last frame of the previous event – and certainly will require rendering when exporting the project.

This some times also happens, when a large amount of clips (taken with ScLive) is dragged from the explorer window to the time line.

Can we expect this to be solved in the next release?

Comments

mysteryno wrote on 5/5/2003, 3:22 PM

I had a similar problem. Seemed to be the combo of capture/render before it got to Vegas. Check out this thread.
https://www.sonicfoundry.com/forums/ShowMessage.asp?MessageID=169326&Page=0

elCutty wrote on 5/6/2003, 1:12 AM

Thank you for the link, but it does not solve the problem.

SonicDennis wrote in that thread:
'With "quantize to frames" ON, you can see where project frames are, because the cursor can only be on them.'
Even with "quantize to frames" ON you can see that the edge of keyboard trimmed (key 4/6)events is NOT on frame nor 1/2 frame boundary when you zoom in to a very high time line resolution. When you make a time selection on the trimmed event, the preview is assuming an inter frame transition showing the last frame of the previous event. Thats all with 25fps PAL DV source and projekt.

Trimming in that high resolution brings back the edge to frame boundaries but I normally do not zoom to that level when trimming in the time line.