PDA

View Full Version : Edge-Drag Caution: Don't Confuse A/V "Clips" with Image "Stills"



Quiet1onTheSet
08-08-2009, 10:53 AM
Absconded here, from a thread which discussed the inappropriate use of "Stretch" (i.e., speed adjust) on an image STILL, resulting in vertical jitter for that Still:

Yes the problem is the speed of the clip. This drove me crazy last year!

A potential problem at the outset here, is that some of us are mistakenly thinking of an Image "Still" in the same way as we would an A/V "Clip", using the term "Clip" to apply to both.

There's a very important distinction between the two, which must be remembered when dragging the edge of each for I/O operations.
But for starters, I prefer to discourage the use of the term term CLIP to apply to image STILLs. Then, I'd like to emphasize that in SpeedEDIT™, the I/O change operation is for both Audio/Video CLIPS and image STILLs; but Stretch (i.e., speed change) operation is only for Audio/Video CLIPS.


I/O operation on a Clip by edge Drag: Simply Drag the edge of an audio or video CLIP to change its I/O point at that edge.
Stretch (i.e., speed change) operation on a Clip by edge ALT+Drag: ALT+Drag the edge of an audio or video CLIP to change its playback speed but [I]conversely...
I/O operation on a Still is by ALT+Drag only! You must apply ALT to the edge-Drag operation on a Still to change its duration from the default length (established in SpeedEDIT™ Preferences).
Stretch (i.e., speed change) operation on a Still is to be avoided. To prevent vertical jitter, resist the temptation to edge drag without the ALT qualifier.
In understanding the logic for that last bullet point above, think this way:

Creating a "Speed Change" on an image STILL, with applied Motion parameters
Until a motion path is created for an image STILL, attempting to apply a "speed change" to an image STILL should be considered counter-intuitive, if not ridiculous.

Therefore...

with an image STILL, you may first elect to change its default length (i.e., duration) by a specified amount via dragging with the ALT requirement (ALT+Drag) from either the left or right edge of said STILL
then, if desired, you may elect to keyframe some motion for that image Still, within Control Tree, using the Position controls.
now, you're able to apply an effective "speed change" to that motion still (yeah, that's oxymoronic, alright!) by ALT+Drag from either the left or right edge again


In summary, do not perform "STRETCH" (i.e., speed change) on a STILL, as you might on a CLIP; instead, ALT+Drag from its left or right edge to change its length (i.e., duration) from its default in SpeedEDIT™ Preferences. If you've already created motion keyframes for the image STILL within Control Tree, using the Position controls, then, this, or any subsequent changing of its length, by Alt+Drag will, in effect, impact its "motion speed" also.


Copyright 2009, Peter Benson, All Rights Reserved

Dufusyte
08-11-2009, 10:09 AM
Since Edge Drag changes the I/O on a video clip, it would be intuitive that Edge Drag would also perform an I/O change on a Still.

SE 2.0: Make it so.

SBowie
08-11-2009, 10:25 AM
Frankly, I've always felt the same way. Have you entered a bug report (or feature request) in the database?

DonJMyers
08-11-2009, 10:49 AM
Accidentally changing speeds of a clip by not following the above directions really threw me for a loop last year. It can make your env editor act weird too. People helped me hash it out back then so NT is aware of it.

I WANT SPEEDEDIT 2.0!

Quiet1onTheSet
08-11-2009, 03:03 PM
Alt+Edge Drag on Clips = Stretch adjust
Edge Drag on Clips = I/O adjust
Alt+Edge Drag on Stills = I/O adjust

With those obvious contradistinctions for adjusting I/O points for clips and stills in NewTek's fine editors, I can't figure out how past feature requests on this issue has never been implemented.

Oh, yes -- it's been requested before, alright -- and if you've felt this annoyance for quite some time, Steve, I wouldn't doubt that even *you've* filed a bug report and/or a feature request on that NewTek editor nuance, right? Steve? STEVE?
:question:

:rolleyes:
Q1

Quiet1onTheSet
08-11-2009, 03:09 PM
Frankly, I've always felt the same way. Have you entered a bug report (or feature request) in the database?


I WANT SPEEDEDIT 2.0!
But why? Steve is indicating it's not in there!
8~

Well -- OK, eh, I mean the idea it's not changed for 2.0 could be construed from his post above...unless he's pulling our chains...
:hey:
Q1

SBowie
08-11-2009, 03:23 PM
I remember it being explained to me at some point in the distant past why it was this way, but I wasn't convinced then either. ;)

I hunted and found several dated (and closed) cases on the topic, but I think the decision to leave it as is might bear review. I always prefer it when a user makes a feature request or bug report rather than me, though. (I enter plenty already, believe me.)

Quiet1onTheSet
08-11-2009, 07:59 PM
I remember it being explained to me at some point in the distant past why it was this way, but I wasn't convinced then either. ;)

I hunted and found several dated (and closed) cases on the topic, but I think the decision to leave it as is might bear review. I always prefer it when a user makes a feature request or bug report rather than me, though. (I enter plenty already, believe me.)My suspicion is that you've doubtless served up a suggestion via a bug or feature request on that, long before you came into the illustrious NewTek fold, mate.
:)

Even so, your most recent post admirably confirms my overarching suspicion: that NewTek is well aware of this intriguing, dualistic behavioral requirement on the part of the enduser, when setting I/O points for clips vis a vis for stills.

Q1