[CinCV TNG] lazy insertion point movement when using keypad

Phyllis Smith phylsmith2017 at gmail.com
Tue Aug 22 18:52:20 CEST 2017

Summary first:
*Playing shows you what has just been played in the compositor window.*  It
is not the same as seeking.  Cinelerra was originally and quite
specifically designed to perform this way.

Frederic's initial question (quotes have been modified to shorten):

> *What is going on here?*
> http://aimvis.de/potentialBuglazyInsertionPointMovementWhenUsingKeypad.
> cinelerra-gg_git20170709-1955.webm
> When using keypad1 and keypad4, the compositor window does not always show
> the frame at the insertion point.
> When clicking with the mouse in the main window, the compositor window
> shows the frame at the insertion point.
> Why is the behavior using keys different from using the mouse?
> So why not adapt the keypad-behavior to the mouse-behavior?

What it used to do:
The last frame "jog" was originally added to pre-load an opengl buffer.  It
also sort of "presets" to replay the last play frame so that if you were
editing it, eg. adjusting a plugin parameter, the last frame would be the
next play target once again.  This is sort of confusing, but that is the
way it was originally coded in HV.

Seeking is different than playing.
When you seek, you reposition to just before the target frame, and since
the play direction has not been established it shows you the next frame.
This produces the expected behaviour when you seek to frame zero; you see
the first frame.  Seeking shows you what you are getting ready to work

What it does now:
When you play, you want to know what you just played so that you know what
matches what you just saw/heard in case that is the desired stuff. * You
don't want the compositor to show you what you have not yet played - you
need to see this frame to analyze/check to see if it is what you want.  *This
behaviour applies to any playing operation, such as the keypad or Frame
forward/Frame reverse buttons.  You can still easily see the actual
insertion point in the zoombar at the bottom of the timeline - sixth button
over or 3rd button from the right side).

Some modified snips:

>   - Current behavior is not intuitive.
>   - It is not usable for precise working, although it seems to be intended
> for
>     precise working.

Cinelerra is not an intuitive program but rather a program that has to be
gradually learned by experience.  It is not easy to learn and without
actually looking at the source code, there will be questions. The way the
play works in conjunction with the compositor and insertion point is just
another one of the things that a Cinelerra user will have to learn.  It is
actually a good method for precisely locating the desired frame.
Frequently, I have found that what seems to be odd behaviours are the only
way that works.

More quotes (shortened/modified):

> My naive hope was, that it was just
> a matter of starting at frame -1 instead of frame 0 ... ;)

GG did look at the program code to see how it works and to make sure it was
working correctly - there is a lot of tedious details to ensuring the
pointer/cursor is where it should be.  It appears to be as originally
designed and actually what he expected.

However, if you come up with a strategy to cover seek, play forward, and
play reverse at different speeds that is context-free (i.e. does not have
statements like "if this case" then "do this" as exceptions) it could be
possible to improve the code, or even create a preference behaviour.


On Mon, Jul 10, 2017 at 11:53 AM, Frederic Roenitz <roenitz at aimvis.de>

> Using the keypad to move the insertion point is great! :)
> But what is going on, here:
> http://aimvis.de/potentialBug-lazyInsertionPointMovementWhen
> UsingKeypad.cinelerra-gg_git20170709-1955.webm
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cinelerra-cv.org/pipermail/cinelerra/attachments/20170822/9aef4315/attachment.html>

More information about the Cinelerra mailing list