From 620a22b2a8c172ed03185e656a82a1187789caa9 Mon Sep 17 00:00:00 2001 From: Simon Larcher Date: Wed, 8 Dec 2010 01:10:38 +0100 Subject: [PATCH] Added anchors to the glossary. Fine tuned the wording in design/index.html The arrows "->" before each item in the glossary give direct links. Use the #anchor of the link to refer to it. Everything from the item name is kept with rules : Two Words = #TwoWords | Two/Words = #Two_Words --- doc/design/index.txt | 25 +++++------ doc/user/outerSpace/Glossary.txt | 75 +++++++++++++++----------------- 2 files changed, 48 insertions(+), 52 deletions(-) diff --git a/doc/design/index.txt b/doc/design/index.txt index 7d35ac233..a78d59ac8 100644 --- a/doc/design/index.txt +++ b/doc/design/index.txt @@ -5,8 +5,12 @@ The vision of the development team defines a modern design for the core of a Non 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. This is made possible by the above-mentioned quality of Lumiera being considered as two strictly separate parts. -Lumiera as a processing core will be able to do anything possibly conceivable and thus enabling it to be used to do any task on video (and audio?), even unrelated to video editing. +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. +.Workflow +**** +The word Workflow is used to name the way tasks can be achieved in an application. Any operation in Lumiera must be possible in the most suitable and stringent fashion. The Workflow is closely related to how flexible the GUI is but also the concern of deeper and more technical parts of the application. +**** === Overview The internal structure of Lumiera is divided in numerous subsystems. @@ -16,7 +20,7 @@ They can be categorized into three main categories plus extra components : ==== link:gui/index.html[Graphical User Interface] User interfaces are basically handled like plugins, consequently it is possible to interface with Lumiera through scripts. It is also possible to create specialized GUIs. -The interface is the closest component to the user, it is purely visual. There the user manipulates, organizes, loads, configures all sorts of datas that are called Assets. These Assets are grouped in a structure called the Session. +The interface is the closest component to the user, it is purely visual. There the user manipulates, organizes, loads, configures all sorts of datas, especially MObjects (media objects) and Assets. These elements are contained within a structure called the Session. ==== The Processing Layer @@ -27,26 +31,21 @@ The Processing layer (or proc) is where the elements from the Session are assemb ==== link:backend/index.html[The Backend] -The backend uses the Low-level model. It does the rendering process and makes a heavy use of the Input/Output System to the screen or to external monitors. - + - + +The backend uses the Low-level model. It allows the rendering and makes a heavy use of the Input/Output System to the screen or to external monitors. +//link:workflow/index.html[The Workflow] -'''' - -link:workflow/index.html[The Workflow] -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -The word Workflow is used to name the way tasks can be achieved in an application. Any operation in Lumiera must be possible in the most suitable and stringent fashion. The Workflow is closely related to how flexible the GUI is but also the concern of deeper and more technical parts of the application. +Extra components +---------------- link:application/index.html[The Application] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -Apart from all things that deal with the internal gear, Lumiera contains several elements related to external elements. +The application controls the initialization and shutdown procedures as well as loading external elements like plugins that are widely used. link:plugins/index.html[Plugins] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -They are key elements in Lumiera since the application relies heavily on this concept of modules. +They are key elements in Lumiera since the application relies heavily on this concept of modules. For example, the GUI of Lumiera is a plugin. diff --git a/doc/user/outerSpace/Glossary.txt b/doc/user/outerSpace/Glossary.txt index 1408fcdf4..9f5f7c2ea 100644 --- a/doc/user/outerSpace/Glossary.txt +++ b/doc/user/outerSpace/Glossary.txt @@ -2,31 +2,30 @@ Glossary ======== - 'NOTE Draft, please help rephrase/review and sort this terms, shorten explanations, the long explanation is the topic of the document above..' - Project:: + anchor:Project[] link:#Project[->]Project:: the top-level context in which all edit work is done over an extended period of time. The Project can be saved and re-opened. It is comprised of the collection of all things the user is working on, it contains all informations, assets, state and objects to be edited. - Session:: + anchor:Session[] link:#Session[->]Session:: the current in-memory representation of the Project when opened within an instance of Lumiera. This is an implementation-internal term. For the GUI and the users POV we should always prefer the term "Project" for the general concept. - Timeline View:: + anchor:TimelineView[] link:#TimelineView[->]Timeline View:: A view in the GUI featuring a given Timeline. There might be multiple views of the same timeline, all sharing the same PlayController. A proposed extension is the ability to 'focus' a timeline view to a sub-Sequence contained within the top-level sequence of the underlying Timeline. (Intended for editing meta-clips) - Track-head/patchbay:: + anchor:Track-head_patchbay[] link:#Track-head_patchbay[->]Track-head/patchbay:: the box in front of a track allowing to control properties of the elements contained within this track, unfold nested tracks and so on. To a large extent, it corresponds to the placement of this track and @@ -39,7 +38,7 @@ explanations, the long explanation is the topic of the document above..' patchbay, that is not the main purpose and they can do things beyond that.. - Timeline:: + anchor:Timeline[] link:#Timeline[->]Timeline:: the top level element(s) within the Project. It is visible within a 'timeline view' in the GUI and represents the effective (resulting) arrangement of media objects, resolved to a finite time axis, to be @@ -54,7 +53,7 @@ explanations, the long explanation is the topic of the document above..' * global pipes, i.e. global busses like in a mixing desk * exactly one top level Sequence - Time Axis:: + anchor:TimeAxis[] link:#TimeAxis[->]Time Axis:: An entity defining the temporal properties of a timeline. A time axis defines the time base, kind of timecode and absolute anchor point. Besides, it manages a set of frame quantisation grids, corresponding @@ -62,14 +61,13 @@ explanations, the long explanation is the topic of the document above..' busses). The GUI representation is a time ruler with configurable time ticks showed on top of the timeline view - - Busses:: + anchor:Busses[] link:#Busses[->]Busses:: A list of 'global Pipes' representing the possible outputs (master busses) similar to audio mixing desk. A bus defines the properties of the rendered output (Framerate, Resolution, Colorformat and so on). Busses are part of a Timeline. - Sequence:: + anchor:Sequence[] link:#Sequence[->]Sequence:: A collection of *Media Objects* (clips, effects, transitions, labels, automation) placed onto a tree of tracks. By means of this placement, the objects could be anchored relative to each other, relative to @@ -80,7 +78,7 @@ explanations, the long explanation is the topic of the document above..' contains just a single root track and sends directly to the master bus of the timeline. - Placement:: + anchor:Placement[] link:#Placement[->]Placement:: A Placement represents a relation: it is always linked to a Subject (this being a Media Object) and has the meaning to place this Subject in some manner, either relatively to other Media Objects, by some @@ -89,7 +87,7 @@ explanations, the long explanation is the topic of the document above..' thus are organised hierarchically and need to be _resolved_ to obtain a specific value (time point, output routing, layering, fade,...) - Pipe:: + anchor:Pipe[] link:#Pipe[->]Pipe:: Conceptual building block of the high-level model. It can be thought off as simple linear processing chain. A stream can be 'sent to' a pipe, in which case it will be mixed in at the input, and you can @@ -98,15 +96,15 @@ explanations, the long explanation is the topic of the document above..' (busses) in each Timeline, each clip automatically creates N pipes (one for each distinct content stream. Typically N=2, for video and audio) - - MediaStream:: + + anchor:MediaStream[] link:#MediaStream[->]MediaStream:: Media data is supposed to appear structured as stream(s) over time. While there may be an inherent internal structuring, at a given perspective any stream is a unit and homogeneous. In the context of digital media data processing, streams are always quantized, which means they appear as a temporal sequence of data chunks called frames. - StreamType:: + anchor:StreamType[] link:#StreamType[->]StreamType:: Classification of a media stream. StreamType is a descriptor record. While external media processing libraries usually do provide some kind of classification already, within lumiera we rely on an uniform yet @@ -119,42 +117,42 @@ explanations, the long explanation is the topic of the document above..' film quality, TV, youtube). - implementation type (e.g. 96kHz 24bit PCM, 2 channels muxed) - intention tag (Source, Raw, Intermediary and Target) - - OutputDesignation:: + + anchor:OutputDesignation[] link:#OutputDesignation[->]OutputDesignation:: A specification denoting where to connect the output of a pipe. It might either be given _absoulutely_, i.e as Pipe-ID, or by an _relative_ or _indirect_ specification - - OutputMapping:: + + anchor:OutputMapping[] link:#OutputMapping[->]OutputMapping:: translates one output designation into another one, e.g. when hooking up a sequence as virtual clip within another sequence - OutputSlot:: + anchor:OutputSlot[] link:#OutputSlot[->]OutputSlot:: opaque descriptor for an output facility, ready to dispose frames of data to be output. - OutputManager:: + anchor:OutputManager[] link:#OutputManager[->]OutputManager:: manages all external outputs of the application and provides output - slots targetting these + slots targetting these. - PlayController:: + anchor:PlayController[] link:#PlayController[->]PlayController:: coordinating playback, cueing and rewinding of a playback position, visible as 'Playhead' cursor in the GUI. When in play state, a PlayController requests and directs a render process to deliver the media data needed for playback. - RenderTask:: + anchor:RenderTask[] link:#RenderTask[->]RenderTask:: basically a PlayController, but collecting output directly, without moving a PlayheadCursor (maybe a progress indicator) and not operating in a timed fashion, but freewheeling or in background mode - Controller Gui:: + anchor:ControllerGui[] link:#ControllerGui[->]Controller Gui:: This can be either a full Software implementation for a Transport control (Widgets for Start/Stop/Rev/Ffw etc) or some Gui managing an Input Device. They share some feature to attach them to controllable gui-entities (Viewers, Timeline Views) - Viewer:: + anchor:Viewer[] link:#Viewer[->]Viewer:: the display destination showing video frame and possibly some effect overlays (masking etc.). When attached to a timeline, a viewer reflects the state of the timeline's associated PlayController, and it @@ -166,21 +164,21 @@ explanations, the long explanation is the topic of the document above..' mere control for sending video to a dedicated monitor (separate X display or firewire) - High Level Model:: + anchor:HighLevelModel[] link:#HighLevelModel[->]High Level Model:: All the session content to be edited and manipulated by the user through the GUI. The high-level-model will be translated by the Builder into the Low Level Model for rendering. - Low Level Model:: + anchor:LowLevelModel[] link:#LowLevelModel[->]Low Level Model:: The generated Processing Graph, to be ``performed'' within the engine to yield rendered output - Builder:: + anchor:Builder[] link:#Builder[->]Builder:: A kind of compiler which creates Low Level/Processing Graphs, by traversing and evaluating the relevant parts of the high-level-model and using the Rules System. - Timeline Segment:: + anchor:TimelineSegment[] link:#TimelineSegment[->]Timeline Segment:: A range in the timeline which yields in one Processing graph, commonly the range between cut points (which require a reconfiguration of the graph). @@ -188,23 +186,23 @@ explanations, the long explanation is the topic of the document above..' // Note by Ichthyo: "Extent" sounds somewhat cool, just it didn't occur to me as a term. // We may well agree on it, if "extent" communicates the meaning better. Up to now, I called it "segment" - Assets View:: + anchor:AssetsView[] link:#AssetsView[->]Assets View:: The windows showing and managing the available things to work with. This are the ingested footage, already composed Clips, available Sub-Projects, Effects, Transitions and internal artefacts. - Rules System:: + anchor:RulesSystem[] link:#RulesSystem[->]Rules System:: Translating the Timeline to the underlying Processing Graphs involves some logic and knowledge about handling/converting data. This may be configued with this Rules System. Typically Lumiera will provide sane defaults for most purposes but may extended/refined for site specific - things. + things. - Processing Graph:: + anchor:ProcessingGraph[] link:#ProcessingGraph[->]Processing Graph:: Rendering is expressed as detailed network of Nodes, each defining a processing step. - Config System/Preferences:: + anchor:ConfigSystem_Preferences[] link:#ConfigSystem_Preferences[->]Config System/Preferences:: TODO: agree on one term here Provides defaults for all kinds of application configurations. These include machine specific configurations for performance @@ -213,13 +211,12 @@ explanations, the long explanation is the topic of the document above..' data. Many settings will then be stored within the project and the Config/Preferences becomes overridden by that. - Input Device:: + anchor:InputDevice[] link:#InputDevice[->]Input Device:: some hardware controler, like a extra Keyboard, Midi Mixer, Jog, .. TODO: decide if the main keyboard as special (global) state. - Focus:: + anchor:Focus[] link:#Focus[->]Focus:: TBD - Cursor:: + anchor:Cursor[] link:#Cursor[->]Cursor:: playback- or edit position -