[Lumiera] Timecode formats and time widget

Ichthyostega prg at ichthyostega.de
Sat Jul 10 04:45:30 CEST 2010

Hash: SHA1

> Brian Rytel <tesla.pictures at gmail.com> writes:
>> note my described method is a convention in all professional NLEs, and 
>> should be considered carefully.

Stefan Kangas schrieb:
> Yes, and I am convinced; I now agree this is the best thing.  However, this 
> probably means dropping the Ardour widget entirely.

> The Ardour widget is of most benefit when one wants to edit only one part of 
> the time code.  Blanking it is very tedious.  If I wish to move to 
> 00:00:15:00 from 01:01:01:01, I have to remember to click the hour part (or
> I have to click it again), and then press no less than 8 digits to fill it
> with zeros.

> The primary benefit is on the other hand exactly this locational memory, 
> since this makes it easy to move forward or backward an exact number of 
> frames, seconds or minutes.

Hi Stefan,
Hi Brian,

at this point I'd propose to be careful and not to draw conclusions too
quickly. When Joel Holdsworth pointed out that we'd need such a timecode
widget, my motivation to propose the Ardour widget was "code reuse":

I.e. what I intended was to copy a fairly mature and reality proven piece
of code and get something in quickly which has quite some level of
functionality. So, Stefan, if you've already put some effort into adapting
the ardour widget, I'd propose that you just finish off this work and not
throw it away or redo everything from start. As an immediate benefit, we'll
get something mature and feature rich NOW.

Besides that, we indeed /should/ continue this discussion about handling
of the timecode widget. We might well decide that we'd need to invent a
completely new timecode widget in the future. But as you all noted already,
this topic is much more involved as it might look at first sight.

Probably it mostly depends on the context of your work which aspects of
time entry are more important. If you're working on typical rather short
video sequences and using min:sec:frames, then, according to my own
experience, you'll end up entering absolute frame values frequently.

OTOH, if you're working on sound and/or on a timeline of several hours length,
and if you're using hh:mm::ss.fract, then it would be an absolute nuisance
if you'd have to enter the seconds and fractional seconds just in order to
address a location 20 minutes later. And using the same widget to enter the
zoom span or the length of a loop creates yet another different situation.

We should note that we'll get several hundreds of instances of this widget
in every average session. Just think of all the labels and markers. Moreover,
each clip will get a properties dialog box, featuring start, end, length and
source position, and probably each of these might use this widget.

Another important point to note is that you can modify each individual field
with the mouse wheel, just by hovering the mouse above it. At least that's
what the Ardour widget provides. That means that you can e.g. move / bounce
a clip, or a label or the start/end points or length of the playback loop
or punch area just with the mouse wheel, and with absolute precision.
(do we need a punch area? probably yes, at least when we want to support
overdubbing. Thus, not immediately in the first version, but probably
at some point in the future)

Another closely related concern is the persisting of GUI state. If it's possible
to switch the timecode mode of this widget, than its just natural that the user
expects this setting to be remembered. And that means, not only as a global
default, but per individual widget, at least for the most prominent ones.
We've always pointed out that the session (proc layer) will care to persist
additional (opaque) values for GUI state; but for this to work we'll need
unique IDs, so the persisted values can be fed back to the right places
in the GUI. Now, as we're getting an arbitrary number of timelines,
sequences, and so on, combined with the requirement to be able to
load "compatible" different versions of the session format, that's
all not so uttermost trivial as it might look at first sight.

Thus, obviously the widget alone has quite a lot of properties and behaviours.
I'd be rather careful not to mix in too much of things which belong into the
realm of general GUI design, ergonomics and workflow.

> This widget also ties in with a very import tool, as I call it the "Time 
> Nudge"...

Brian, you're absolutely right that we need some kind of nudge feature and
the ability to "kick" clips. But I'd rather propose not to build too much logic
here directly into the timcode display widget as such, before we're getting a
more clear picture of the overall GUI. Well... the idea of accepting additional
input formats like "+10" is certainly a good start

> A timeline usually has a set base (starting) TC value, usually an hour value,
> but could be any arbitrary TC value, and the widget will need to be aware of
> that value.

Closely related to that, maybe you should note that Lumiera will use "relative"
values to a much greater extent than you'll be familiar with from conventional
NLEs. Because in Lumiera, objects don't just "snap magnetic" through a GUI input
feature, but instead of that, objects are added by a so called "Placement",
which can be absolute or relative in time, and will provide additional
modes of placement.
Thus, even if the timeline has indeed a start value, the track tree and
the contained objects are part of a sequence and should by default rather
be placed relatively either to the sequence, or to the individual track, or
in special cases relative to preceding objects, relative to a label or even
to a certain position in the source material. Basically, each object has a
way of remembering /how/ it was attached, and to which point of reference.
Obviously, this creates some additional problems to solve which doesn't
exist in a NLE with just one timeline which just trades everything in
absolute time values (e.g. Cinelerra)


Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org


More information about the Lumiera mailing list