[gephex-devel] handling of time in gephex-0.5

[Georg Seidel]

I had a rather long discussion with martin about the best way
to handle time in gephex-0.5.

Currently, the core passes a "current time" to each unit in the update
method. There is no mention of time in a linktype.

First, we identified three main "use cases" for the current time:

   1/ units want to check, wether it's input links have changed
      since the last call, without comparing the content of the links
      (which would work fine for numbers, but less well for images)

   2/ some sources need the time (signal generator, audio sine-wave
      generator, ...)

   3/ media-streams (think video and audio or midi) must be synchronized
      (e.g. in a avi writer)

Our proposed solution involves two parts:

    a/ each link has a time interval which is managed by the core
       it indicates the duration where this link is "valid"
       (for example, a video image from a vide with 25 fps is valid
       for an interval of 1/25 second)

    b/ units that need time simply have two extra input ports of type
       number (maybe one input of type time_interval?). The unit expects
       one start and one end time and produces output for this time
       interval

Notes on a/:
   The time interval of a link is initially set at a source unit.
   Imagine a webcam. Let's say the core is updated with 25 fps, and
   the webcam delivers new images with 12.5 fps.
   The core is started at time 0.
   The webcam-unit is updated first, and the output link gets the
   time interval [0, 1/25[.
   The second time the webcam unit is updated (at time 1/25 s), it does
   not deliver a new image (it signals this by returning false from
   update), so the core just changes the time interval of the link
   to [0, 2/25[.
   The time interval for other links is set analogously.
   One interesting case are feedback loops. Here, the core must change
   the time interval at one point of the loop.

Notes on b/: Making time a regular input has different advantages:
   * it allows more units to behave deterministically
   * it allows offline rendering, given that all used units are
     deterministic with respect to time (you just can pass a logical
     time to the units instead of the real time).
One disadvantage is that it requires more management effort in the core
(it must be made sure that all time inputs of all units are connected
  to the same time...).

We are quite confident that the three use cases from above can be
solved this way (I'm going to expand on this in an extra message).

Open issues:
   * how can the core attach meta-information (the time intervals)
     to links, in a way that allows units to read that information?
   * how do we "mark" time input ports of units?

This is not very polished yet. It reflects the current status of our
discussion, which I wanted to document here.

Georg