diff --git a/doc/design/backend/index.txt b/doc/design/backend/index.txt index 19de56002..9e8c3826c 100644 --- a/doc/design/backend/index.txt +++ b/doc/design/backend/index.txt @@ -1,22 +1,22 @@ Design Documents: Backend ========================= -What follows is a summary regarding the design of Lumiera's *Data Handling Backend* +What follows is a summary of Lumiera's *Data Handling Backend* This is the foundation layer responsible for any high performance or high volume -data access. Within Lumiera, ther are two main kinds how data is handled: +data access. Within Lumiera, there are two main kinds of data handling: -* The Session and the object models manipulated through the GUI is kept in memory. - It is backed by a _storage backend,_ which provides database like storage and +* The Session and the object models manipulated through the GUI are kept in memory. + They are backed by a _storage backend,_ which provides database-like storage and especially logging, replaying and ``Undo'' of all ongoing modifications.. * Media data is handled _frame wise_ -- as described below. The backend uses *memory mapping* to make data available to the program. This is somewhat different to the more common open/read/write/close file access, while giving superior performance and much better memory utilization. -The data backend must be capable to handle more data than will fit into the memory +The data backend must be able to handle more data than will fit into the memory or even address space on 32 bit architectures. Moreover, a project might access more files -than the OS can handle at a any time, thus the for _Files used by the Backend,_ it needs a +than the OS can keep open simultaneously, thus the for _Files used by the Backend,_ it needs a *FilehandleCache* to manage file handle dynamically. Which parts of a file are actually mapped to physical RAM is managed by the kernel; diff --git a/doc/design/index.txt b/doc/design/index.txt index aee3c476b..f42c91ac8 100644 --- a/doc/design/index.txt +++ b/doc/design/index.txt @@ -10,18 +10,19 @@ Lumiera Design Documents // Menu : append child plugins // Menu : append child workflow -The goal of Lumiera is to provide a professional tool for video editing on +Lumiera is to be a professional tool for video editing on GNU/Linux systems. The vision of the development team defines a modern design -for the core of a Non-Linear Editing software. One of the key aspect of Lumiera -is the strong separation between the user interface and the processing core. -Lumiera as a software will come along with a GTK GUI but that does not make this -exclusive, any other GUI could be written as well as scripts to drive the core. +for the core of a Non-Linear Editing software. A key aspect of Lumiera +is strong separation between the user interface and the processing core. +Lumiera will have a GTK GUI but that will not be +exclusive; other GUIs can be written, even by users, +as well as scripts to drive the core. This is made possible by an ongoing effort to decrease coupling. Each major component in the application strives to be open to extensions, but closed against external modification. The presentation, the model and the ``performing'' of the model are separate and self-contained parts of the application. Lumiera -as a processing core will be able to do anything possibly conceivable, therefore it -may be used to do any task on video (and audio?), even unrelated to video editing. +as a processing core will be able to perform any conceivable +task on video and audio, even some unrelated to video editing. .Workflow ***************** @@ -35,19 +36,19 @@ but is also the concern of deeper and more technical parts of the application. Overview -------- -The internal structure of Lumiera is divided into numerous subsystems. This -overview will provide a general description of the major areas that make up -Lumiera from the highest down to the lowest level. Lumiera can be considered to -be composed of three main areas with an additional extra components. We discuss -theses areas below. +Lumiera is built from numerous subsystems. This +overview will provide a general description of the major components +from the highest to the lowest level. Lumiera +is composed of three main areas with a few additional extra components. We discuss +these areas below. Graphical User Interface ~~~~~~~~~~~~~~~~~~~~~~~~ -User interfaces are basically implemented as a plugin. As a consequence, it is +User interfaces are implemented as plug-ins. As a consequence, it is possible to interface with Lumiera through scripts. It is also possible to create -specialised GUIs. The interface is the closest component to the user. It is -a purely visual interaction with the user. There the user manipulates, +specialised GUIs. The interface is the component that is closest to the user. It +provides purely visual interaction with the user. There the user manipulates, organizes, loads, configures all sorts of data, especially MObjects (media objects) and Assets. These elements are contained within a structure called the Session. + -> link:gui/index.html[GUI design documents] @@ -56,10 +57,10 @@ objects) and Assets. These elements are contained within a structure called the The Processing Layer ~~~~~~~~~~~~~~~~~~~~ -The processing layer (``Proc-layer'' or ``proc'') covers several closely related aspects. -While the user works with the GUI, all the clips, effects and other components presented +The processing layer (``Proc-layer'' or ``proc'') has several closely related aspects. +When the user works with the GUI, all the clips, effects and other components presented there are actually stored within the _Session model_ (``high-level model''). Any editing -operations initiated by the user are actually performed here. Next, after each change, +operations initiated by the user are actually performed there. Next, after each change, a component known as _the Builder_ assembles the contents of this model and transforms them to form a network of nodes, which can be _performed_ efficiently for rendering. Often, we refer to this node structure as the ``low-level model''. On rendering or @@ -89,7 +90,7 @@ The Application ~~~~~~~~~~~~~~~ The application controls the initialization and shutdown procedures as well as -loading external elements such as plugins, which are widely used throughout +loading external elements such as plug-ins, which are widely used throughout Lumiera. It acts as the framework which supports core component operations. This framework is complemented by a library of commonly used components, algorithms and data structures. + -> link:application/index.html[Application framework] @@ -98,11 +99,11 @@ framework is complemented by a library of commonly used components, algorithms a link:plugins/index.html[Plugins] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -Plugins play an important role within Lumiera since the application relies +Plug-ins play an important role within Lumiera since the application relies heavily on current FLOSS implementations and external libraries. Moreover, the -application is envisioned to be configurable and can be extended in various +application will be configurable and can be extended in various ways; whenever some extension isn't permanent or will be used only on demand, it is packaged as a separate module into a plug-in. For example, the GUI of Lumiera is a plugin. + --> design doruments regarding the link:plugins/index.html[Plugins] +-> design documents regarding the link:plugins/index.html[Plugins] diff --git a/doc/design/model/index.txt b/doc/design/model/index.txt index 2541c63c5..31dd74534 100644 --- a/doc/design/model/index.txt +++ b/doc/design/model/index.txt @@ -2,4 +2,5 @@ Design Documents: Model ======================= * two models: high-level and low-level - * RfC: link:{rfc}/../rfc_pending/ProcHighLevelModel.html[high-level model basics] + * RfC: link:{rfc}/../rfc/ProcHighLevelModel.html[high-level model basics] + diff --git a/doc/index.txt b/doc/index.txt index 268479de4..4063cb80b 100644 --- a/doc/index.txt +++ b/doc/index.txt @@ -1,3 +1,4 @@ + = Documentation = This documentation section contains documentation for both users and developers. @@ -29,7 +30,7 @@ used as design notebook, featuring day-to-day design sketches, notes but also quite some more persistent planning. Finished documentation text is constantly moved over to the documentation section(s) of the Lumiera website. --> access the Proy-Layer link:http://lumiera.org/wiki/renderengine.html[TiddlyWiki online here] +-> access the Proc-Layer link:http://lumiera.org/wiki/renderengine.html[TiddlyWiki online here] == Media and Presentations == diff --git a/doc/user/intro/intro.txt b/doc/user/intro/intro.txt index 174468b5f..42c71d13d 100755 --- a/doc/user/intro/intro.txt +++ b/doc/user/intro/intro.txt @@ -46,13 +46,11 @@ link:{ldoc}/technical/overview.html[The Inner Core] Vision ------ -NOTE: this section is still in discussion - Lumiera strives to be a *professional non-linear video editing system*. It is important to note that by ``professional'' we do not imply ``commercial'' nor -``industrial''. We do, however, wish to convey an attitude or frame of mind in -the approach made to such work; not its goal, requirement or purpose. - +``industrial''. We do, however, wish to convey an attitude or frame of mind +in the approach made to such work; not its goal or purpose. + Professionalism implies _doing work with sincerity and being subject to any kind of wider goal, demand, or purpose._ When it comes to editing film, this wider goal, demand, or purpose might be artistry, a narration or have meaning to @@ -74,12 +72,10 @@ aspects film production tools will have to exhibit to aspire to be labelled requires crisp-quality results with no concessions made throughout the entire workflow that might compromise quality of the final work. A common requirement is the ability to reproduce all rendering - calculations down to a single digit. - - ??What does this mean, a single digit?? + calculations down to the last bit. Performance and Productivity:: - Professionals want to get things done on time ??and content??, but + Professionals want to get things done on time, but with control over all detail. The fine balance of these goals is a central goal of workflow design and usability. @@ -149,8 +145,8 @@ Processing video (and audio) data can be conceived as a graph (more precisely a _directed acyclic graph_). In this model of video processing, data flows along the edges of the graph and is processed at the nodes. -The following figure depicts manipulating video data as a graph. The nodes of -the ??root?? of the graph are where data input occurs. From there, the data moves on +The following figure depicts manipulating video data as a graph. The nodes at +the top of the graph are where data input occurs. From there, the data moves on to the next nodes: the direct siblings of the root. Here, the video data is pre-processed. All other operations on the data can be represented by nodes, and data flows from one operation to the next along the nodes of the diff --git a/doc/user/manual.txt b/doc/user/manual.txt index 5a1e397e8..d5952352a 100644 --- a/doc/user/manual.txt +++ b/doc/user/manual.txt @@ -1,8 +1,8 @@ Lumiera User Manual =================== -The plan is to create the users manual later in a colaborative -fashion, similar to what turned out so effective for Cinelerra. +The plan is to create the users manual later in a collaborative +fashion, which was effective for Cinelerra. This work is postponed until the software is actually working.