[Lumiera] Which timecode formats do we want?

Brian Rytel tesla.pictures at gmail.com
Fri Jul 9 06:54:53 CEST 2010

> One way is
> to have it be a nicely formatted time code (I like how the APP one
> looks), and clicking it gives you a blank field to enter arbitrary
> digits, which then get formatted upon hitting enter.  Optionally, you
> could format them as you type.
First I'd like to note that I think the ardour-style widget is handy in a
transport-control type window, like avid's logging/playback, or, more likely
as an OSD for a dedicated full-screen playback monitor, or as APP calls it
the "Reference Window" [window -> reference window]. (let me know if that
wasn't clear)

I would actually like the "live colon" feature, as sometimes I get lost as
to which digit I'm when entering. With the samples and non-video alternative
time options, the 'live' symbols may help. Also, when one double-clicks the
APP TC box, it holds the time and you can manually edit single values, not
all NLE's handle that the same way.

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.

This widget also ties in with a very import tool, as I call it the "Time
I have the timeline selected either in the timeline window or in the
playback window, and enter: '+' 10 and the cursor jumps 10 frames.

Some NLE's assign this function through the TC display/edit dialog, showing
the entered value (+10) and then using a boolean to come up with the new TC
value and moves the cursor there. Others, as CT mention use a
pseudo-commandline entry that happens to be active with that combination of
selected GUI items and keys.

If a fair amount of coding will be necessary, we should probably decide how
the 'Time nudge' function works and interacts with the TC widget now.


On Thu, Jul 8, 2010 at 8:49 PM, Stefan Kangas <skangas at skangas.se> wrote:

> Brian Rytel <tesla.pictures at gmail.com> writes:
> > @Stefan, just checked ardour
> Thank you for your continued efforts to help me improve this area.  It
> seems we have essentially two different paradigms, and I do not think
> they can be combined.
> Let us be clear about what we are discussing:
> The Ardour widget assumes the user clicks on the correct part of the
> widget, since it can not edit digits to the left of that.  It only moves
> to the right as you type, completing the edit when the far right is
> reached.  Also, it keeps whatever was to the left of the edit.  It can
> even keep what was to the right if the user presses enter before having
> filled in all possible digits.
> The opposite paradigm is to blank the time code when it is clicked, and
> have the user enter a new position exactly.  This is what you are
> suggesting we use, and as I will explain, I am beginning to agree.  Bare
> with me, though.
> > Having to click to TC widget 4 times to enter a TC location is maddening.
> Is
> > there a way to have it take all the numbers entered and simply move them
> > "over" to the next highest field?
> If you want to edit all four locations at once, you must click to the
> far left, on the hour digits.
> > My non-programmers concept:
> >
> > 00:00:00:(00) <- I click here
> > and input 1004
> [...]
> > the input dialog knows only (2) digits per dialog (as it does now),
> > but rather than limiting further entry, it would pass (10) to the next
> > dialog?
> I think it would not be very intuitive to try to force the two paradigms
> together in this way.  In the case of clicking the frame part it might
> make sense to move digits along to the left while typing.  But if the
> user clicks the seconds (SS) part and types in 1004, the user would be
> right to assume the edit is complete at that point since there is no
> more room for digits.  When she then begins some other work, the widget
> will keep consuming key presses and move the digits left as new ones are
> typed.
> I simply do not think it makes sense in the context of this widget.  It
> will surely confuse people more than it will help.
> [...]
> > note my described method is a convention in all professional NLEs, and
> > should be considered carefully.
> 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.  These benefits could easily be gained
> otherwise, say by a move function where you can elect to move this or
> that much forward or backward (IIRC, APP has this), or one could imagine
> adding an extension to the standard "blanking" widget where, say, the
> letter "x" is taken to mean "whatever was in this spot before".
> We can think about how we want to present this to the user.  One way is
> to have it be a nicely formatted time code (I like how the APP one
> looks), and clicking it gives you a blank field to enter arbitrary
> digits, which then get formatted upon hitting enter.  Optionally, you
> could format them as you type.
> Thoughts?
>      Stefan Kangas
> _______________________________________________
> Lumiera mailing list
> Lumiera at lists.lumiera.org
> http://lists.lumiera.org/cgi-bin/mailman/listinfo/lumiera
> http://lumiera.org/donations.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lumiera.org/pipermail/lumiera/attachments/20100708/c710b682/attachment.html>

More information about the Lumiera mailing list