[Lumiera] Timecode formats and time widget

Brian Rytel tesla.pictures at gmail.com
Sat Jul 10 08:15:09 CEST 2010


>
> 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.
>
Hence my suggestion of the daisy-chain, however Stefan noted that this was
possible by (double?) clicking the hours and entering a similar value, which
seems OK by me.

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.
>
This is the purpose of the Time Nudge, rather than entering 7-8 digits (or
more for samples), you type in the amount you want, ie + 200000 for twenty
minutes.

We should note that we'll get several hundreds of instances of this widget
> in every average session.
>
I am less familiar with the design, but any NLE or DAW I've used has 2
in/out TCs and 1 master TC in the clip review window, and the same total for
the program window. Total 6, occasionally it is included on the timeline
element as well, so one would have to account for those, but I know no way
of actively using 2 timelines simultaneously, especially with the advanced
nesting implemented here. Even with many timelines, viewers and program
controls, you'd be <100 in any usable arrangement.

I perhaps don't understand why you'd use a widget with advance sync, and
assignable TC functions (=math) to display state data assigned to clips.
While the I/O numbers would have to update and be editable relevant to the
clip's settings, I would believe (and perhaps quite incorrectly) that this
could be accomplished through either a database-GUI function or a
bi-directional command entry through the GUI (and now I clearly see the
advantage of building an NLE on a DB!).

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.

The reason I bring this up is as follows:
With the timeline or program window targeted there are several options as
how to translate a 'nudge' into a useful action. (eg, command, widget)
What about the I/O TC inputs?

There is no reason to have them active with a targeted GUI object other than
the the I/O TC dialog itself.
It is common and logical to be able enter +2000 to move the IN point further
20 secs, rather than move the cursor to the in-point and then enter +2000
into the main playback dialog and the reset the IN point value.

I brought this up so a discussion could be had about how to handle this: in
the widget? or uni or bi-directional access to the the proc/command?
I have no particular suggestion as I am to unfamiliar with the architecture,
but I can see how making a decision about that now could save some hassle
later.

Conclusion, like CT I'm OK with the Ardour-based widget for now, so long as
it will not adversely affect a future replacement.

As usual, if anything is unclear let me know. Translating right-brain and
visual concepts into words & visa versa isn't simple.


> B.J.M.R.
>


On Fri, Jul 9, 2010 at 7:45 PM, Ichthyostega <prg at ichthyostega.de> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> 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)
>
> Cheers,
> Hermann
>
>
>
>
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iEYEARECAAYFAkw33soACgkQZbZrB6HelLIGcACbBwqKOHv5QMHLRmmnx8UWXOdU
> NQMAoIy6HKrb6N/5GmUafRlOLXyt4t64
> =obGI
> -----END PGP SIGNATURE-----
> _______________________________________________
> 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/20100709/5da8b52a/attachment.html>


More information about the Lumiera mailing list