Lumiera
The new emerging NLE for GNU/Linux
State Final
Date 2008-03-06
Proposed by Ichthyostega

Architecure Overview

This proposal intends to capture envisioned Architecture of the Application.

Overview of Lumiera Architecture

The SVG source of this drawing is maintained in GIT

Description

  • the Application has three Layers: Vault, Steam and Stage.
    [at the time of this writing, those three layers were named “Backend”, “Proc” and “GUI”]

  • the Application shall be completely functional without GUI (script-driven)

  • all IO, media data fetching, processing and bookkeeping falls within the realm of the Vault Layer

  • all media object manipulation, deciding and configuration is the Steam Layer’s job

  • extensible by plugins on all levels, highly configurable, but not totally componentized (micro kernel) architecture

  • strong separation between high-level and low-level areas of the Application

  • the user/GUI manipulates a high-level model whereas rendering is based on a corresponding low-level model

  • stored Session (state) is comprised of high-level model, a collection of Assets and accompaning configuration

  • (possibly) several storage backends, abstracted out by a common interface

Comments

  • Alcarinque made some design drafts for the UI. Here is the SVG source (converted from OODraw by Ichthyo 2011). This is not a technical draft at all, it is just an idea.

  • Wouldn’t the Config Rules (embedded Prolog) also interact with the High Level Model? Or would that be expanding its scope too much? I imagine default/user configurable settings such as explicit !LocatingPin placement vs Relative !LocatingPin placement. For example, in an AMV, or any music video actually, the positioning of clips should be always relative against the audio/music. However, if you are editing a scene in a movie, you want the next scene to appear relative to the last scene played. In the first, you want to keep the scenes always synced up against the audio, while in the latter, you just want the scenes to appear one after another. --- PercivalTiglao

  • Yes, indeed, that is what I am planning. The drawing above just doesn’t show every connection. The interaction between high-level model and rules system mostly goes via the "session defaults", which are facts 'and' rules. Thus, in your example, the user would just use the "default placement". My Intention was to use ''tags'' to quite some extent. The user would be able to tag the source footage, and then rules can kick in when a certain tag applies. Incidentally, integrating prolog is immediately on the agenda, because first we want to flesh out the very basic system and get to work basic rendering. Until then, I use a "mock" implementation of the query/rules system, which just returns some hard wired defaults.  — Ichthyostega

Conclusion

Accepted. The drawing was moved into the GIT tree, hopefully it will be maintained in future.

Back to Lumiera Design Process overview