[Lumiera] Timeline, Timecode-widget and "Quantisation framework"

Ichthyostega prg at ichthyostega.de
Thu Oct 20 04:22:26 CEST 2011

Hi Mike,

just saw your recent changes in the 'timeline' branch.

I haven't tried your latest version, but it is very likely that you're about
to run into an area which is half-finished and not fully ready to be used.

Some notes:

* Timecode widget: Stefan Kangas extracted that from the Ardour codebase and
  basically adapted it to Lumiera. At that point we noticed, that this widget
  contains a host of time / frame alignment logic, which actually would rather
  belong into a generic library solution. We previously had already started such
  a library; so I put some efforts into reworking and extending it, so that it
  can handle "timecode formats" and can be extended later to handle all those
  tricky cases, when several different time/frame grids interact (practical
  example: you have footage in 60fps and you're building a timeline for 25fps).

  Basically I got just to the point of being able to generate a simple SMPTE
  timecode format (hours, mins, secs, frames). Not much beyond that. For
  example, to integrate drop-frame would require a bit of reworking of the
  code beforehand -- at that point I decided to put that aside, because we
  don't need it to build the first render pipeline. Finishing these efforts
  would likely cost *me* about one month of work (and I am well into that
  topic, which is quite tricky in some details).

* that explains the TODO's you found at several places in the GUI code.
  My intention was to *remove* everything from the GUI which deals directly
  with manipulating timecodes. Rather, the goal should be that the timecode
  widget just receives a TimeSpan, QuTime or QuTimeSpan (the latter needs
  to be written) and just invokes the format method on these, instead of
  doing any timecode formatting logic directly (as it does now)

* where do these damn "time grids" come from?
  I noticed that you extracted the following sequence from some unit-test:

TimeGrid::build("test-time-grid", 25);
QuTime qVal (when, "test-time-grid");
FrameNr count (qVal);

  As it stands, this is perfectly valid and correct, but it doesn't
  make much sense. Because originally, the intention was as follows:

  * somewhere in the *session* the TimeGrid is built. Probably when
    we create the model element for the timeline and connect it to
    some output running with 25fps. If we'd reconnect to another
    output running with 30fps, than the grid would be redefined
    or changed.

  * the *player* generates the running time values. (The content of the
    variable "when") The player knows the TimeGrid to use only *by name*
    (i.e. the player knows only the ID "test-time-grid" of the frame grid
    to use, but doesn't care for any details, which are indeed encapsulated
    deep within the session). Behind the scenes, there is a lookup in a
    registry to access the current definition of this time grid.

  * the qVal gets feed up to the GUI (from a background job updating
    the current time position). The timecode widget is able to accept
    a QuTime value and creates a SMPTE timecode formatted value from
    this, and just puts that to display.

* finally, regarding the time mutation. You tried to build a time mutation
  to change both the start point and the length of a selection in one step.
  Actually there is a comment (pointing to TICKET #797 ) proposing to do so.

  Just there is a catch (which explains why this special SetTimeSpan doesn't
  exist yet): TimeSpan is larger than the other time values, because it holds
  both a start point and a duration. It would be possible to allow for that.
  Either, we could redefine all these mutations to be double the size they
  are right now, so they could piggyback this additional value. Well. that's
  a bit ugly, but easy to achieve. Another possibility would be to create
  a special kind of mutation, inheriting directly from the interface.

  But actually at that point, I realised that we need something different here.
  And we need the same thing on the Player interface I am working on right now.
  What we need is not feeding a single change. Rather, we need a "live"
  connection, so we can feed continuous changes to a target timespan. In your
  case the target would be the current selection timespan. In the cases relevant
  for the player, this would be the connection to the current "playhead"
  position and the connection to the running timecode display.

Indeed, I've built and tested such a facility two months ago. Which prompts me,
that I should rather urgently bring my changes from branch 'player' to master
now. Overall, that 'player' is far from being finished, but at least it compiles
ok at the moment -- thus I'll do a merge, including your already
finished part with the zoom slider, and try to get that to master.


More information about the Lumiera mailing list