Lumiera consists of three major parts:
Graphical User Interface (GUI)
Processing layer (“Proc-layer”)
Backend for storage and access
In this section, we discuss the user’s perspective when working with the GUI.
Although Lumiera will initially ship with a standard, default GUI, we do not presume that this GUI will be suitable for all uses.
We expect there to be multiple, different GUIs, each designed for different kinds of tasks. We expect that some of these will be written by users, and the proc-layer is designed to make this easy.
Indeed, Lumiera can even work
satisfactorily without a GUI, for example, for special purposes
(e.g. as headless rendernode ← or frameserver
←). Scripts will eventually be written
to facilitate automated processing.
Now it is time to take a look at the preliminary Lumiera GUI:
We expect this GUI to change once we are at the point of having feedback from actual users.
The screenshot of the GUI presented above is more or less the standard GUI when
it is started for the first time without any user configuration etc. A second
viewer is planned for later to be added to the default. We support a much more
sophisticated screen concept ← to adapt to different
workplaces and workflows.
At a first glance, the GUI might seem somewhat overwhelming, something similar
to the cockpit of a jumbo jet. However, nearly all the bells and whistles can
be subdivided into groups according to their functionality. The following
sub-sections discusses the more prominent groupings.
The viewer is an area where footage and the assembled edit can be played back and investigated.
Obviously, support for audio will also be provided. As there are many sources that
can be displayed, a viewer is attached to a source via the viewer switch board.
Timelines, probe points, wire taps and individual clips are examples of sources
that can be attached to a viewer. Moreover, the number of viewers open at any one
time is only limited by the hardware, and each viewer can be collapsed or hooked
up to a beamer or monitor.
The preliminary layout in the current GUI is rather provisional — a final decision
has yet to be taken on where the transport controls will be located. In later
versions of the standard GUI, the transport controls will change. There is even
a possibility that the transport controls will be allocated their own GUI element.
Transport controls are devices that are controlled by widgets or by some input device
(MIDI, control surface, etc) so the look-and-feel of the transport control
widget may vary, depending on what the transport controls have been assigned
to. Irrespective of their look-and-feel, they are connected to a play
A play controller coordinates playback, cueing and rewinding. Transport
controls are ganged when they attach to the same play controller.
A timeline is a container that provides a time axis and an output. There may be
connections to various output designations, each with a different configuration.
A more elaborate production setup will use several timelines, one for each distinct
output configuration. A timeline does not temporally arrange material, this is
performed by a sequence, which can be connected (snapped) to a timeline.
A typical film will define many sequences, but will only have a few timelines. A
sequence contains a number of tracks which are ordered in a hierarchy. Tracks do
not have any format associated with them and more or less anything can be put
into a track. Consequently, audio and video material can equally be assigned to
a track, there is no discrimination between audio and video in the Lumiera
concept of a track.
A timeline must be assigned to viewer and transport control if playback viewing is desired.
In most cases, these connections are created automatically, on demand: Just playing some
footage for preview creates a simple internal timeline.
The GUI provides a separate bus view, showing the global pipes. These are the
master busses for each kind of output (image and sound) and collect the output of
subgroups together in a manner similar to an audio mixing desk. Any pipe is just a
means of collecting, mixing or overlaying output produced by other pipes.
A simple (linear) chain of effects can be applied within each pipe.
Most pipes are managed automatically, e.g. the pipes corresponding to
individual clips, or the pipes collecting output from transitions, from nested
sequences and from groups of tracks. At some point, at the timeline level, all
processed data is collected within the aforementioned global pipes to form the
small number of output streams produced by rendering and playback. Each timeline
uses a separate set of global pipes.
An Asset View can be conceived as the timeline’s book keeper: it manages the
various constituents in the timeline. Moreover, in addition to managing timeline
constituents, raw material, clips, bins (folders) and effects are managed by the
Asset View, i.e., typical management operations including, deleting, adding,
naming, tagging, grouping into bins, etc. all occur here.
There are various kinds of assets available in any project:
all available effects and transitions
user defined “effect stacks” and effect collections ("effect palette")
internal artefacts like sequences and automation data sets
markers, labels, tags and similar kinds of meta data
Actually, the same underlying data structure is used to implement the
asset view with folders, clip bins and effect palettes, and the timeline
view with tracks, clips and attached effects. Technically, there is no
difference between a track or a clip bin — just the presentation appears
different. Timeline contents can be viewed, just like assets, for bookkeeping
purposes, and the contents of a clip bin can be played like a storyboard.