Ichthyostega
b556d2b770
Some sections of the Lumiera website document meeting minutes, discussion protocols and design proposals from the early days of the project; these pages were initially authored in the »Moin Moin Wiki« operated by Cehteh on pipapo.org at that time; this wiki backed the first publications of the »Cinelerra-3« initiative, which turned into the Lumiera project eventually. Some years later, those pages were transliterated into Asciidoc semi-automatically, resulting in a lot of broken markup and links. This is a long standing maintenance problem problem plaguing the Lumiera website, since those breakages cause a lot of warnings and flood the logs of any linkchecker run.
151 lines
6.5 KiB
Text
151 lines
6.5 KiB
Text
[options="autowidth"]
|
|
|====================================
|
|
|*State* | _Final_
|
|
|*Date* | _2008-10-10_
|
|
|*Proposed by* | Ichthyostega
|
|
|====================================
|
|
|
|
|
|
|
|
the Marble Mode
|
|
---------------
|
|
|
|
[quote]
|
|
``dual working styles -- build up from small pieces of clay +
|
|
or cut away the unneeded parts from a block of marble''
|
|
|
|
While the usual UI of video editors quite well supports a working style
|
|
assembling the result from small building blocks by relying on clips (media
|
|
objects)
|
|
|
|
|
|
|
|
Description
|
|
~~~~~~~~~~~
|
|
This proposal stems from an discussion on the Mailinglist starting with the
|
|
quote from Walter Murch »Marble and Clay«.
|
|
+
|
|
It is thought to be in support and to complement _nasa_'s
|
|
link:/rfc/DelectusShotEvaluator.html[RfC: Delectus Shot Evaluator]
|
|
|
|
The central Idea is to remove the difference between ``viewing'' ⟷ ``editing'',
|
|
i.e. the media viewer and the timeline/Sequence on the other hand.
|
|
Lumiera is designed to handle multiple Sequences, which can even be embedded
|
|
arbitrarily in one another (the so called _virtual clips_ or _meta-clips_).
|
|
Basically, Sequences are a comparatively
|
|
cheap resource, so the idea is to create a new Sequence on-the-fly to do the
|
|
viewing already based on a complete timeline. It is up to the user finally to
|
|
promote one of these workbench-like timelines to become ``the'' master timeline.
|
|
|
|
To make this usable, in the GUI there should be a slightly different
|
|
representation which aims at reducing vertical screen usage. Also the track
|
|
heads could be reduced, e.g. we don't need controls for mixing and panning, the
|
|
effect stacks could be reduced to a simple mark indicating that there is any
|
|
effect in a given time range, anything concerned with the fine points of
|
|
wiring, tweaking effects and controlling automation could be left out
|
|
deliberately. This would allow us to have several independent timelines
|
|
above/below each other. There could be at least two, maybe even three or four
|
|
``slots'' which could be allocated by a timeline to display. Every time you open
|
|
a new media, a new Sequence will be created on the fly and a new timeline
|
|
display of this Sequence will be available, replacing the least recently used
|
|
timeline display slot. Of course, re-visiting an already opened media will
|
|
bring back the corresponding timeline in the state you left it, with markers,
|
|
notes, maybe even trimmings and added clips. Contrast this GUI mode with the
|
|
usual working mode (the »clay mode«), where there is _one_ central timeline,
|
|
probably with tabs to switch between multiple independent Sequences (including
|
|
the ones which actually are embedded in another timeline as meta-clips)
|
|
|
|
Basically, each of these timelines has a separate, independent transport, but
|
|
transports can be locked together, and in locked state you can displace/offset
|
|
the locked partners relative to one another. Moreover, there would be at least
|
|
two viewer windows which would be automatically connected to receive the output
|
|
of the timelines as new timelines are placed in the visible slots to work with.
|
|
To round things up, we need good key bindings for navigation, and of course you
|
|
can liberally mark parts and spill them over to another timeline, either
|
|
overwriting or shifting existing footage there.
|
|
|
|
Technically, to support this working mode, _opening a media_ would:
|
|
|
|
* create a clip containing the whole media
|
|
* on-the-fly create new Sequence containing this clip
|
|
* allocate the next usable display slot and create a timeline display
|
|
featuring this Sequence there
|
|
|
|
Initially this new Sequence would be anonymous. But the moment you do the first
|
|
non-trivial modification there (like adding a label, trimming off parts, adding
|
|
/deleting tracks), the new Sequence would be promoted to be a named and
|
|
persisted entity, which from then on could itself serve as a new
|
|
``pseudo-media''. It would appear as an asset on its own (probably in a special
|
|
sub category), and it could be used as a source to create clips from. This way,
|
|
you could work with your media, prepare it, augment it even by adding effects
|
|
like colour correction. And because it's a real Sequence, you could do
|
|
non-trivial things there right in-place, like adding new sub-tracks, placing
|
|
other media on them -- and then later on use this prepared media like a real
|
|
media captured from camera source.
|
|
|
|
Finally, there should be the possibility to ``play'' a clip bin, thereby
|
|
on-the-fly creating a new Sequence filled with all the clips in the order they
|
|
were arranged in the bin. This would yield a bridge to the more clip-oriented
|
|
working style and also provide a cheap implementation of the ``sparse timeline''
|
|
or ``storyboard mode''
|
|
|
|
|
|
|
|
Tasks
|
|
^^^^^
|
|
* have several switchable _perspectives_ or working modes in the GUI
|
|
* associate a _workflow state_ with each Sequence, to track when an Sequence
|
|
is just anonymous, gets a named entity, is a clip-bin-tied Sequence, or
|
|
finally is the master Sequence connected to the global output pipes section.
|
|
* work out the details of the ``display slot allocation''
|
|
* provide an ``opening media'' compound function, comprised of
|
|
* creating the clip covering the whole media (./) (already implemented)
|
|
* creating a new Sequence and populating it with this clip
|
|
* make locked-together transports work
|
|
* in the GUI (transport controls)
|
|
* for coordinating the corresponding playback/render schedules (playback
|
|
controller, which is located in the core according to our current
|
|
planning)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Rationale
|
|
^^^^^^^^^
|
|
Lumiera is not pioneering the video editing by computers. We are sort of
|
|
second-generation (or even third generation) of computer based editing systems.
|
|
The tradition of conventional, film based editing clearly shows us these two
|
|
quite different working approaches, which obviously can have quite some impact
|
|
on the resulting style and rhythm of the final movie. The distinguishing
|
|
property of the working style to be supported by the »marble mode«s is that it
|
|
bypasses the state of creating and organising clips, but rather directly
|
|
evolves the footage into the final cut. This working style is dual to the
|
|
common clip based approach, none of them is superior or inferior, thus we
|
|
should actively support both working styles.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Comments
|
|
--------
|
|
|
|
Final
|
|
~~~~~
|
|
|
|
Discussed at the link:{ldoc}/devel/meeting_summary/2011-04-13.html#_marble_mode[Apr.2011 developer meeting]. +
|
|
Everyone likes this and we want to have this. But this is rather a concept
|
|
which needs a lot more discussion for the implementation. Further details may
|
|
follow where these things are worked out.
|
|
|
|
Christian Thaeter:: 'Thu 14 Apr 2011 03:06:42 CEST'
|
|
|
|
|
|
''''
|
|
Back to link:/x/DesignProcess.html[Lumiera Design Process overview]
|