ichthyo/LUMIERA.clone
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Merge latest documentation / RfC

Browse source
This commit is contained in:
Fischlurch 2010-12-17 21:23:35 +01:00
commit d4c9997eb7
15 changed files with 293 additions and 93 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

9
___Documentation___
View file

@ -1,9 +0,0 @@
|This is the Lumiera Documentation Tree|
Lumiera documentation is meant to be self contained and included in the main tree.
The 'current' documentation is prepared, collected and tracked in a 'documentation' branch
of the main repository; there, documentation resides in the /doc subdirectory, while the
actual source goes into /src
Moreover, the /doc subdirectory of the documentation tree is linked into the
Lumiera website.

11
admin/rfc.sh
View file

@ -4,7 +4,7 @@ shopt -s extglob
function usage()
{
less -F <<"EOF"
less <<"EOF"
Script to maintain Lumiera RFC's
usage:
@ -22,6 +22,7 @@ commands (with <mandatory> and [optional] parameters):
show <rfcs> [regex] - Read RFC's (matching 'regex')
create <title> - Create a new RFC
edit <rfc> [chapter] - Edit RFC at chapter
asciidoc <rfc> - pass the rfc.txt to 'asciidoc' command
comment <rfc> - Add a new comment to a RFC
draft <rfc> - Change RFC to Draft state
final <rfc> - Change RFC to Final state
@ -237,7 +238,7 @@ function edit()
{
# filename lineoffset chapter
EDITOR="${EDITOR:-$(git config --get core.editor)}"
EDITOR="${EDITOR:-VISUAL}"
EDITOR="${EDITOR:-$VISUAL}"
local file="$1"
local line=0
@ -370,6 +371,12 @@ edit)
git add "$name"
fi
;;
asciidoc)
name=$(unique_name "$1")
if [[ "$name" ]]; then
asciidoc "${name}"
fi
;;
draft)
name=$(unique_name "$1")
if [[ "$name" ]]; then

25
doc/design/index.txt
View file

@ -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.

44
doc/devel/rfc_pending/EngineInterfaceOverview.txt
View file

@ -41,8 +41,8 @@ _corresponds to a single data stream_ to be rendered. Thus, when the play
in _playing_ or _paused_ state, typically multiple corresponding render
processes exist.
* there is an displayer- or output slot, which got allocated on creation of the
process
* there is an displayer- or output slot, which got allocated on creation
of the process
* the process disposes calculated data frames "into" this slot
* the process can be paused/started and stopped (aborted, halted).
* some processes allow for changing parameters dynamically (e.g. speed,
@ -52,23 +52,31 @@ processes exist.
.Process parameters
A process is linked to a single stream data format (a ->
link:StreamTypeSystem.html[stream implementation type]). + It is configured
with _frame quantisation_ and _timings_, and a _model port_ identifier and
_channel selector_.
link:StreamTypeSystem.html[stream implementation type]). +
It is configured with _frame quantisation_ and _timings_, and a _model port_
identifier and _channel selector_.
quantisation::
translates time values into frame numbers. (In the most general
case this is a function, connected to the session)
timings::
a definition to translate global model time units in real clock time,
including _alignment_ to an external time grid.
model port::
a point in the (high level) model where output can be produced. +
This might be a global pipe in one of the model's timelines, or
it might be a _probe point_.
channel::
within the session and high level model, details of the stream
implementation are abstracted. Typically, a global pipe (master bus
or subgroup) corresponds to a multichannel stream, and each of these
channels might be hooked up to an individual render process
(we have to work out if that's _always the case_ or just under
_some circumstances_)
quantisation:: translates time values into frame numbers. (In the most general
case this is a function, connected to the session) timings:: a definition to
translate global model time units in real clock time, including _alignment_ to
an external time grid. model port:: a point in the (high level) model where
output can be produced. +
This might be a global pipe in one of the model's timelines, or
it might be a _probe point_.
channel:: within the session and high level model, details of the stream
implementation are abstracted. Typically,
a global pipe (master bus or subgroup) corresponds to a multichannel
stream, and each of these channels might be hooked up to an
individual render process (we have to work out if that's _always the
case_ or just under _some circumstances_)
[NOTE]
===================

7
doc/devel/rfc_pending/NormalizedDeviceCoordinates.txt
View file

@ -58,6 +58,11 @@ Tasks
^^^^^
Discussion
~~~~~~~~~~
Pros
^^^^
@ -75,7 +80,7 @@ Alternatives
Rationale
~~~~~~~~~
TBD

5
doc/devel/rfc_pending/ProcPlacementMetaphor.txt
View file

@ -109,6 +109,11 @@ Tasks
Discussion
~~~~~~~~~~
Pros
^^^^
* with just one concept, we get a lot of issues right, which many conventional

5
doc/devel/rfc_pending/RenderOptimizer.txt
View file

@ -32,6 +32,11 @@ Tasks
^^^^^
Discussion
~~~~~~~~~~
Pros
^^^^

7
doc/devel/rfc_pending/ResourceManagementBudgeting.txt
View file

@ -73,6 +73,11 @@ Tasks
// * item ...
Discussion
~~~~~~~~~~
Pros
^^^^
// add just a fact list/enumeration which make this suitable:
@ -88,7 +93,7 @@ Cons
Alternatives
------------
^^^^^^^^^^^^
//alternatives: if possible explain/link alternatives and tell why they are not
viable:

7
doc/devel/rfc_pending/ResourceManagementProfiling.txt
View file

@ -134,6 +134,11 @@ Tasks
// * item ...
Discussion
~~~~~~~~~~
Pros
^^^^
// add just a fact list/enumeration which make this suitable:
@ -149,7 +154,7 @@ Cons
Alternatives
------------
^^^^^^^^^^^^
//alternatives: if possible explain/link alternatives and tell why they are not
viable:

5
doc/devel/rfc_pending/Roadmap-first.txt
View file

@ -136,6 +136,11 @@ Please review and discuss this proposal, consider if it's of any use setting it
up this way...
Discussion
~~~~~~~~~~
Pros
^^^^
* doesn't hinder us

5
doc/devel/rfc_pending/StreamTypeSystem.txt
View file

@ -10,8 +10,7 @@
Stream Type System
------------------
Especially in the Proc-Layer, we need a framework to deal with different
"kinds" of media streams.
+
"kinds" of media streams. +
This is the foundation to be able to define what can be connected and to
separate out generic parts and isolate specific parts.
@ -69,7 +68,7 @@ or selection regarding each of these levels.
conversions. Examples for Prototypes are: stereoscopic (3D) video versus the
common flat video lacking depth information, spatial audio systems
(Ambisonics, Wave Field Synthesis), panorama simulating sound systems (5.1,
7.1,...), stereophonic and monaural audio.
7.1,...), binaural, stereophonic and monaural audio.
* Besides the distinction by prototypes, there are the various *media
implementation types*. This classification is not necessarily hierarchically
related to the prototype classification, while in practice commonly there

7
doc/devel/rfc_pending/ThreadsSignalsAndImportantManagementTasks.txt
View file

@ -113,6 +113,11 @@ We have appstate::maybeWait() which already does such a loop. It needs to be
extended by the proposed things above.
Discussion
~~~~~~~~~~
Pros
^^^^
// add just a fact list/enumeration which make this suitable:
@ -127,7 +132,7 @@ Cons
Alternatives
------------
^^^^^^^^^^^^
//alternatives: if possible explain/link alternatives and tell why they are not

160
doc/devel/rfc_pending/WebsiteNavigation.txt Normal file
View file

@ -0,0 +1,160 @@
WebsiteNavigation
=================
// please don't remove the //word: comments
[grid="all"]
`------------`-----------------------
*State* _Idea_
*Date* _Mi 08 Dez 2010 11:32:32 CET_
*Proposed by* Ichthyostega <prg@ichthyostega.de>
-------------------------------------
[abstract]
********************************************************************************
The Lumiera website is assumed to accumulate a lot of content. Thus we need
to care about making that content accessible, to help finding the relevant
topics and to keep the overall structure intact. This RfC is to collect,
discuss and agree upon the guidelines and requirements.
********************************************************************************
Description
-----------
//description: add a detailed description:
Issues to care
~~~~~~~~~~~~~~
Navigation::
The page hierarchy becomes at least 5 levels deep, likely even deeper.
When reading a page, the current subtree leading down to this page should
be right at hand; especially access to the siblings and the parent's siblings
is important. For re-accessing content, it is necessary to be able to drill
down to an known location (``within the design docs, detailing the application,
I need the configuration section'') +
-> we need an *auto generated navigation* and an embedded *menu tree widget* in the web pages.
Tagging::
There should be an easy way to categorise individual pages *by keyword(s)*
and an automatically generated indexing by tags, possibly with an per tag
overview page.
Search::
The usual *site search*. It should include the contents of the issue tracker.
Even today such a scoped search is valuable and even necessary for working
with the informations collected within the Lumiera project
Sanity::
Each relevant page needs to be reachable. There are some additional pages and
especially subdirectories which should not be linked into the website navigation.
Moreover, all (internal) links on the pages should be valid. +
-> this could be addressed by a **sanity checker script**
Usage situations
~~~~~~~~~~~~~~~~
(a) working on content
^^^^^^^^^^^^^^^^^^^^^^
Working on content should be readily accessible for _everyone_. One time contributions
are especially encouraged. This leads to the following usage scenario:
A contributor has some informations to share or wants to do some additions or modifications.
(S)he locates somehow the place where relevant informations are stored, adds some text,
possibly adds a new page or splits another page in two.
_Note_: no awareness of the issues of navigation can be assumed. The occasional contributor
won't notice any concern which isn't right at hand.
(b) maintaining a subsystem
^^^^^^^^^^^^^^^^^^^^^^^^^^^
Some person(s) will be responsible for a subsystem or some segment of the informations
on the website. This responsibility is content centric. It might include frequent rearranging,
regrouping and reordering of pages to accommodate the increasing scope of informations.
_Note_: while here some awareness of website organisational issues can be assumed,
any requirement to care for external organisational issues is a burden and distracts
from the actual work to be done -- thus it is likely to be short circuited or postponed
``for later''. Note especially, reorganising content in a subsection *must not* incur
the burden of re-doing the same reorganisation steps mirrored in some central navigation
configuration or table of contents. (this is a knock out criterion)
(c) maintaining the website
^^^^^^^^^^^^^^^^^^^^^^^^^^^
The website maintainer is responsible for the overall sanity of the website, without
being familiar with all details of ongoing work in some part or section of the information.
Another concern here is the outward perception of the website, which might incur changes
on the top level navigation or some rewording of overview pages.
_Note_: this kind of work is rather unrewarding. There is the danger of collisions with the
work of the subsystem maintainer
Conclusion: Requirements for any navigation solution
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
* ability to to pick up a nested page structure
* ability to cope with any additions and changes in the lower levels automatically, without help by the user
* ability to override:
- not including some subdirectories
- including links-to-external at arbitrary positions
optional/additional features
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
The following features would be handy, but can be considered optional
* ability to change the displayed title of a page in the navigation
* ability to control the ordering of pages in the navigation
* complete manual override of the visible content of a specific subdirectory
Tasks
~~~~~
// List what would need to be done to implement this Proposal in a few words:
// * item ...
Discussion
~~~~~~~~~~
Pros
^^^^
// add just a fact list/enumeration which make this suitable:
// * foo
// * bar ...
Cons
^^^^
// fact list of the known/considered bad implications:
Alternatives
^^^^^^^^^^^^
//alternatives: explain alternatives and tell why they are not viable:
Rationale
---------
//rationale: Describe why it should be done *this* way:
//Conclusion
//----------
//conclusion: When approbate (this proposal becomes a Final)
// write some conclusions about its process:
Comments
--------
//comments: append below
//endof_comments:

14
doc/template/rfc.txt vendored
View file

@ -25,13 +25,17 @@ Description
Tasks
~~~~~
// List what would need to be done to implement this Proposal in a few words:
// * item ...
// List what needs to be done to implement this Proposal:
// * first step ([green]#✔ done#)
// * second step [,yellow]#WIP#
Discussion
~~~~~~~~~~
Pros
^^^^
// add just a fact list/enumeration which make this suitable:
// add a fact list/enumeration which make this suitable:
// * foo
// * bar ...
@ -44,14 +48,14 @@ Cons
Alternatives
------------
^^^^^^^^^^^^
//alternatives: explain alternatives and tell why they are not viable:
Rationale
---------
//rationale: Describe why it should be done *this* way:
//rationale: Give a concise summary why it should be done *this* way:

75
doc/user/outerSpace/Glossary.txt
View file

@ -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