Glossery terms sorted
This commit is contained in:
parent
130fc1bf26
commit
acec8ad71c
1 changed files with 170 additions and 165 deletions
|
|
@ -5,6 +5,108 @@ Glossary
|
||||||
'NOTE Draft, please help rephrase/review and sort this terms, shorten
|
'NOTE Draft, please help rephrase/review and sort this terms, shorten
|
||||||
explanations, the long explanation is the topic of the document above..'
|
explanations, the long explanation is the topic of the document above..'
|
||||||
|
|
||||||
|
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.
|
||||||
|
|
||||||
|
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.
|
||||||
|
|
||||||
|
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.
|
||||||
|
|
||||||
|
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
|
||||||
|
characteristics, File and Plugins Paths and configuration data and so
|
||||||
|
on. Note that this only provides defaults for otherwise not yet set
|
||||||
|
data. Many settings will then be stored within the project and the
|
||||||
|
Config/Preferences becomes overridden by that.
|
||||||
|
|
||||||
|
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)
|
||||||
|
|
||||||
|
anchor:Cursor[] link:#Cursor[->]Cursor::
|
||||||
|
playback- or edit position
|
||||||
|
|
||||||
|
anchor:Focus[] link:#Focus[->]Focus::
|
||||||
|
TBD
|
||||||
|
|
||||||
|
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.
|
||||||
|
|
||||||
|
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.
|
||||||
|
|
||||||
|
anchor:LowLevelModel[] link:#LowLevelModel[->]Low Level Model::
|
||||||
|
The generated Processing Graph, to be ``performed'' within the engine
|
||||||
|
to yield rendered output
|
||||||
|
|
||||||
|
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.
|
||||||
|
|
||||||
|
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
|
||||||
|
|
||||||
|
anchor:OutputManager[] link:#OutputManager[->]OutputManager::
|
||||||
|
manages all external outputs of the application and provides output
|
||||||
|
slots targetting these.
|
||||||
|
|
||||||
|
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
|
||||||
|
|
||||||
|
anchor:OutputSlot[] link:#OutputSlot[->]OutputSlot::
|
||||||
|
opaque descriptor for an output facility, ready to dispose frames
|
||||||
|
of data to be output.
|
||||||
|
|
||||||
|
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
|
||||||
|
'plug' the output of a pipe to another destination. Further, effects
|
||||||
|
or processors can be attached to the pipe. Besides the global pipes
|
||||||
|
(busses) in each Timeline, each clip automatically creates N pipes
|
||||||
|
(one for each distinct content stream. Typically N=2, for video and
|
||||||
|
audio)
|
||||||
|
|
||||||
|
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
|
||||||
|
Constraint or simply absolute at (time, output). Placements are used
|
||||||
|
to stitch together the objects in the high-level-model. Placements
|
||||||
|
thus are organised hierarchically and need to be _resolved_ to obtain
|
||||||
|
a specific value (time point, output routing, layering, fade,...)
|
||||||
|
|
||||||
|
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.
|
||||||
|
|
||||||
|
anchor:ProcessingGraph[] link:#ProcessingGraph[->]Processing Graph::
|
||||||
|
Rendering is expressed as detailed network of Nodes, each defining a
|
||||||
|
processing step.
|
||||||
|
|
||||||
anchor:Project[] link:#Project[->]Project::
|
anchor:Project[] link:#Project[->]Project::
|
||||||
the top-level context in which all edit work is done over an extended
|
the top-level context in which all edit work is done over an extended
|
||||||
|
|
@ -12,12 +114,80 @@ explanations, the long explanation is the topic of the document above..'
|
||||||
comprised of the collection of all things the user is working on, it
|
comprised of the collection of all things the user is working on, it
|
||||||
contains all informations, assets, state and objects to be edited.
|
contains all informations, assets, state and objects to be edited.
|
||||||
|
|
||||||
|
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
|
||||||
|
|
||||||
|
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.
|
||||||
|
|
||||||
|
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
|
||||||
|
external objects, absolute in time. A sequence can connect to the
|
||||||
|
global pipes when used as top-level sequence within a timeline, or
|
||||||
|
alternatively it can act as a virtual-media when used within a
|
||||||
|
meta-clip (nested sequence). In the default configuration, a Sequence
|
||||||
|
contains just a single root track and sends directly to the master bus
|
||||||
|
of the timeline.
|
||||||
|
|
||||||
anchor:Session[] link:#Session[->]Session::
|
anchor:Session[] link:#Session[->]Session::
|
||||||
the current in-memory representation of the Project when opened within
|
the current in-memory representation of the Project when opened within
|
||||||
an instance of Lumiera. This is an implementation-internal term. For
|
an instance of Lumiera. This is an implementation-internal term. For
|
||||||
the GUI and the users POV we should always prefer the term "Project"
|
the GUI and the users POV we should always prefer the term "Project"
|
||||||
for the general concept.
|
for the general concept.
|
||||||
|
|
||||||
|
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
|
||||||
|
abstract classification which is owned by the project and geared to
|
||||||
|
fit the internal needs, especially for the wiring and connecting.
|
||||||
|
A Lumiera stream type is comprised of the parts
|
||||||
|
- media kind (Video, Image, Audio, MIDI, Text,... )
|
||||||
|
- prototype (open ended collection of semantical kinds of media,
|
||||||
|
examples being stereoscopic, periphonic, monaural, binaural,
|
||||||
|
film quality, TV, youtube).
|
||||||
|
- implementation type (e.g. 96kHz 24bit PCM, 2 channels muxed)
|
||||||
|
- intention tag (Source, Raw, Intermediary and Target)
|
||||||
|
|
||||||
|
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
|
||||||
|
to the outputs configured for this timeline (through the global
|
||||||
|
busses). The GUI representation is a time ruler with configurable time
|
||||||
|
ticks showed on top of the timeline view
|
||||||
|
|
||||||
|
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
|
||||||
|
rendered for output or viewed in a Monitor (viewer window).
|
||||||
|
Timeline(s) are top-level and may not be further combined. A timeline
|
||||||
|
is comprised of:
|
||||||
|
* Time axis, defining the time base
|
||||||
|
* Play Controller (WIP: discussion if thats belongs to the timeline
|
||||||
|
and if we want a 1:N relation here). Note by Ichthyo: yes, our
|
||||||
|
current discussion showed us that a play controller rather gets
|
||||||
|
allocated to a timeline, but isn't contained therein.
|
||||||
|
* global pipes, i.e. global busses like in a mixing desk
|
||||||
|
* exactly one top level Sequence
|
||||||
|
|
||||||
|
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).
|
||||||
|
|
||||||
|
// 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"
|
||||||
|
|
||||||
anchor:TimelineView[] link:#TimelineView[->]Timeline View::
|
anchor:TimelineView[] link:#TimelineView[->]Timeline View::
|
||||||
A view in the GUI featuring a given Timeline. There might be multiple
|
A view in the GUI featuring a given Timeline. There might be multiple
|
||||||
views of the same timeline, all sharing the same PlayController. A
|
views of the same timeline, all sharing the same PlayController. A
|
||||||
|
|
@ -38,120 +208,6 @@ explanations, the long explanation is the topic of the document above..'
|
||||||
patchbay, that is not the main purpose and they can do things beyond
|
patchbay, that is not the main purpose and they can do things beyond
|
||||||
that..
|
that..
|
||||||
|
|
||||||
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
|
|
||||||
rendered for output or viewed in a Monitor (viewer window).
|
|
||||||
Timeline(s) are top-level and may not be further combined. A timeline
|
|
||||||
is comprised of:
|
|
||||||
* Time axis, defining the time base
|
|
||||||
* Play Controller (WIP: discussion if thats belongs to the timeline
|
|
||||||
and if we want a 1:N relation here). Note by Ichthyo: yes, our
|
|
||||||
current discussion showed us that a play controller rather gets
|
|
||||||
allocated to a timeline, but isn't contained therein.
|
|
||||||
* global pipes, i.e. global busses like in a mixing desk
|
|
||||||
* exactly one top level Sequence
|
|
||||||
|
|
||||||
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
|
|
||||||
to the outputs configured for this timeline (through the global
|
|
||||||
busses). The GUI representation is a time ruler with configurable time
|
|
||||||
ticks showed on top of the timeline view
|
|
||||||
|
|
||||||
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.
|
|
||||||
|
|
||||||
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
|
|
||||||
external objects, absolute in time. A sequence can connect to the
|
|
||||||
global pipes when used as top-level sequence within a timeline, or
|
|
||||||
alternatively it can act as a virtual-media when used within a
|
|
||||||
meta-clip (nested sequence). In the default configuration, a Sequence
|
|
||||||
contains just a single root track and sends directly to the master bus
|
|
||||||
of the timeline.
|
|
||||||
|
|
||||||
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
|
|
||||||
Constraint or simply absolute at (time, output). Placements are used
|
|
||||||
to stitch together the objects in the high-level-model. Placements
|
|
||||||
thus are organised hierarchically and need to be _resolved_ to obtain
|
|
||||||
a specific value (time point, output routing, layering, fade,...)
|
|
||||||
|
|
||||||
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
|
|
||||||
'plug' the output of a pipe to another destination. Further, effects
|
|
||||||
or processors can be attached to the pipe. Besides the global pipes
|
|
||||||
(busses) in each Timeline, each clip automatically creates N pipes
|
|
||||||
(one for each distinct content stream. Typically N=2, for video and
|
|
||||||
audio)
|
|
||||||
|
|
||||||
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.
|
|
||||||
|
|
||||||
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
|
|
||||||
abstract classification which is owned by the project and geared to
|
|
||||||
fit the internal needs, especially for the wiring and connecting.
|
|
||||||
A Lumiera stream type is comprised of the parts
|
|
||||||
- media kind (Video, Image, Audio, MIDI, Text,... )
|
|
||||||
- prototype (open ended collection of semantical kinds of media,
|
|
||||||
examples being stereoscopic, periphonic, monaural, binaural,
|
|
||||||
film quality, TV, youtube).
|
|
||||||
- implementation type (e.g. 96kHz 24bit PCM, 2 channels muxed)
|
|
||||||
- intention tag (Source, Raw, Intermediary and Target)
|
|
||||||
|
|
||||||
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
|
|
||||||
|
|
||||||
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
|
|
||||||
|
|
||||||
anchor:OutputSlot[] link:#OutputSlot[->]OutputSlot::
|
|
||||||
opaque descriptor for an output facility, ready to dispose frames
|
|
||||||
of data to be output.
|
|
||||||
|
|
||||||
anchor:OutputManager[] link:#OutputManager[->]OutputManager::
|
|
||||||
manages all external outputs of the application and provides output
|
|
||||||
slots targetting these.
|
|
||||||
|
|
||||||
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.
|
|
||||||
|
|
||||||
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
|
|
||||||
|
|
||||||
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)
|
|
||||||
|
|
||||||
anchor:Viewer[] link:#Viewer[->]Viewer::
|
anchor:Viewer[] link:#Viewer[->]Viewer::
|
||||||
the display destination showing video frame and possibly some effect
|
the display destination showing video frame and possibly some effect
|
||||||
overlays (masking etc.). When attached to a timeline, a viewer
|
overlays (masking etc.). When attached to a timeline, a viewer
|
||||||
|
|
@ -164,59 +220,8 @@ explanations, the long explanation is the topic of the document above..'
|
||||||
mere control for sending video to a dedicated monitor (separate X
|
mere control for sending video to a dedicated monitor (separate X
|
||||||
display or firewire)
|
display or firewire)
|
||||||
|
|
||||||
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.
|
|
||||||
|
|
||||||
anchor:LowLevelModel[] link:#LowLevelModel[->]Low Level Model::
|
|
||||||
The generated Processing Graph, to be ``performed'' within the engine
|
|
||||||
to yield rendered output
|
|
||||||
|
|
||||||
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.
|
|
||||||
|
|
||||||
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).
|
|
||||||
|
|
||||||
// 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"
|
|
||||||
|
|
||||||
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.
|
|
||||||
|
|
||||||
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.
|
|
||||||
|
|
||||||
anchor:ProcessingGraph[] link:#ProcessingGraph[->]Processing Graph::
|
|
||||||
Rendering is expressed as detailed network of Nodes, each defining a
|
|
||||||
processing step.
|
|
||||||
|
|
||||||
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
|
|
||||||
characteristics, File and Plugins Paths and configuration data and so
|
|
||||||
on. Note that this only provides defaults for otherwise not yet set
|
|
||||||
data. Many settings will then be stored within the project and the
|
|
||||||
Config/Preferences becomes overridden by that.
|
|
||||||
|
|
||||||
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.
|
|
||||||
|
|
||||||
anchor:Focus[] link:#Focus[->]Focus::
|
|
||||||
TBD
|
|
||||||
|
|
||||||
anchor:Cursor[] link:#Cursor[->]Cursor::
|
|
||||||
playback- or edit position
|
|
||||||
|
|
|
||||||
Loading…
Reference in a new issue