Is there a justification for this somewhat odd behaviour?
Is it more logical?  More usable (I think not!)  Easier to program?


I think it has to do with the idea that the playback head is positioned on
a sample rather than on a frame.  When you say "move ahead one frame", you
aren't actually moving to the next frame; you are moving ahead an amount
of time equal to the length of one frame, and seeing what happens during
that time.



The confusing thing is that the behaviour is at odds with the analogy of the timeline window being like a strip of film. With that analogy you would think that you were seeing and navigating with the playback head moving from frame to frame and projecting the current frame while sitting on top of it.

However the current behaviour makes it clear: a unit on the counter is not a frame of film as displayed in the compositor. And this is good.

It makes the situation transparent when the project frame-rate is different from the asset frame rate. You can even use footage at 23.97 fps and a project framerate of 60 fps and cinelerra still works logically and well. The counter counts the position of the playback head and if it passes over a new frame the compositor display is updated and if not it isn't updated.

The analogy of the timeline window being like a strip of film falls apart anyway when you are using interlaced footage.

Graham

_______________________________________________
Cinelerra mailing list
[email protected]
https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra

Reply via email to