From 790deb16b6627d598e7d05be271b462a6ec97291 Mon Sep 17 00:00:00 2001 From: Ichthyostega Date: Fri, 15 Aug 2008 07:05:43 +0200 Subject: [PATCH] finished the drawing, added an example session containing 2 EDLs with track tree --- doc/devel/draw/high-level-model.svg | 1834 +++++++++++++++++++++------ wiki/renderengine.html | 6 +- 2 files changed, 1457 insertions(+), 383 deletions(-) diff --git a/doc/devel/draw/high-level-model.svg b/doc/devel/draw/high-level-model.svg index c83f45153..f5f0af8e5 100644 --- a/doc/devel/draw/high-level-model.svg +++ b/doc/devel/draw/high-level-model.svg @@ -25,11 +25,11 @@ borderopacity="1.0" inkscape:pageopacity="0.0" inkscape:pageshadow="2" - inkscape:zoom="1" - inkscape:cx="326.94415" - inkscape:cy="612.06042" + inkscape:zoom="1.4142136" + inkscape:cx="298.73663" + inkscape:cy="289.68644" inkscape:document-units="px" - inkscape:current-layer="lay_Basics" + inkscape:current-layer="lay_Label" inkscape:window-width="1352" inkscape:window-height="1016" inkscape:window-x="0" @@ -48,16 +48,69 @@ gridopacity="0.09019608" showguides="true" inkscape:guide-bbox="false" - inkscape:object-nodes="false" + inkscape:object-nodes="true" gridoriginx="0px" gridtolerance="10000" - inkscape:object-paths="true" + inkscape:object-paths="false" objecttolerance="1" inkscape:object-points="false" inkscape:guide-points="true" guidetolerance="5" /> + + + + + + + + + + + + + + + + + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + @@ -996,35 +988,6 @@ - - - - - - - @@ -1315,114 +1278,146 @@ + id="g_attachAuto_Legend"> - + transform="translate(480,30)" + id="g_proc_obj_2"> - - + id="g4508" + transform="translate(-440,95)"> + + + - + + + + + + + + Auto - - - - - + sodipodi:linespacing="100%" + id="text_Auto" + style="font-size:10px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:100%;writing-mode:lr-tb;text-anchor:start;color:#000000;fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:0.60000002;stroke-linecap:butt;stroke-linejoin:miter;marker:none;marker-start:none;marker-mid:none;marker-end:none;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:0.71062275;visibility:visible;display:inline;overflow:visible;enable-background:accumulate;font-family:Bitstream Vera Sans">Auto + + + - + id="path4098" + sodipodi:nodetypes="cc" + d="M 540,197.36218 L 540,222.36218" + style="color:#000000;fill:none;fill-opacity:1;fill-rule:evenodd;stroke:#788888;stroke-width:1;stroke-linecap:round;stroke-linejoin:round;marker:none;marker-start:none;marker-mid:none;marker-end:none;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;visibility:visible;display:inline;overflow:visible;enable-background:accumulate" /> + + + + + + + + + + - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + x + + + + + + + + + + + + + + + + + x + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Meta + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + global Pipes + + + + EDL-1 + + + + EDL-2 + + + + inkscape:groupmode="layer"> Several pipes may be joined together by a transition, which in the general case simultanously treats N media streams. Commonly, a transition simply combines two streams into one output. transition, which in the general case simultaneously treats N media streams. Commonly, a transition simply combines two streams into one output. Besides absolute and relative placement, there is also the possibility of a placement to stick directly to another MObject's placement, e.g. to attach an effect to a clip or to connect an automation data set to an effect. + id="flowSpan4850">media stream type the respective pipe will process. Thus, effectively each channel (sub)clip gets its own specifically adapted processing pipe. + The Session contains several independent EDLs plus an output bus section (global Pipes). Each EDL holds a collection of MObjects placed within a Tree of Tracks. The wiring, if not defined locally within an MObject's placement, is derived by searching up this track tree and utilizing the wiring plug locating pins found there, if applicable. Besides routing to a global pipe, wiring plugs can also connect to the source port of an Meta-Clip. diff --git a/wiki/renderengine.html b/wiki/renderengine.html index fc2ae74ee..34cf791f3 100644 --- a/wiki/renderengine.html +++ b/wiki/renderengine.html @@ -564,7 +564,7 @@ For every Asset we generate a __Ident tuple__ and a long ID (hash) derived from 
The Asset Manager provides an Interface to some internal Database holding all Assets in the current Session and System state. It may be a real Database at some point (and for the moment it's a Hashtable). Each [[Asset]] is registered automatically with the Asset Manager; it can be queried either by it's //identification tuple// or by it's unique ID.
-
+
Placing an MObject relatively to another object such that it should be handled as //attached//  to the latter results in several design and implementation challenges. Actually, such an attachment creates a cluster of objects. The typical use case is that of an effect attached to a clip or processing pipe.
 * attachment is not a globally fixed relation between objects, rather, it typically exists only for some limited time span (e.g. the duration of the basic clip the effect is attached to)
 * the order of attachment is important and the attached placement may create a fork in the signal flow, so we need a way for specifying reproducibly how the resulting wiring should be
@@ -576,8 +576,8 @@ The first step towards an solution is to isolate the problem; obviously we don't
 * retrieve and break the attachment when //deleting.//
 
 !!Implementation notes
-Attachment is managed within the participating placements, mostly by special [[locating pins|LocatingPin]]. Attachment doesn't necessarily nail down an attached object, rather the behaviour depends on the type of the object and the locating pins actually involved, especially on their order and priority. For example, if an {{{Placement<Effect>}}} doesn't contain any locating pin defining a temporal position, the the attachment will result in the placement inheriting the temporal placement of the attachment head (i.e. the clip this effect has been attached to). But, if on the contrary the effect in question //does// have an additional locating pin, for example relative to another object or even to a fixed time position, this one will "win" and determine the start position of the effect &mdash; it may even move the effect out of the time interval covered by the clip, in which case the attachment has no effect on the clip's processing pipe.
-The attachment relation is hierarchical and has a clearly defined //active// and //passive// side: The attachment head is above, but plays the role of the passive partner. But note, this does not mean we are limited to a single attachment head. Actually, each placement has a list of locating pins and thus can attach to several other placements. For example, a transition attaches to at least two local pipes (clips).
+Attachment is managed within the participating placements, mostly by special [[locating pins|LocatingPin]]. Attachment doesn't necessarily nail down an attached object to a specific position, rather the behaviour depends on the type of the object and the locating pins actually involved, especially on their order and priority. For example, if an {{{Placement<Effect>}}} doesn't contain any locating pin defining a temporal position, then the attachment will result in the placement inheriting the temporal placement of the //attachment head// (i.e. the clip this effect has been attached to). But, if on the contrary the effect in question //does// have an additional locating pin, for example relative to another object or even to a fixed time position, this one will "win" and determine the start position of the effect &mdash; it may even move the effect out of the time interval covered by the clip, in which case the attachment has no effect on the clip's processing pipe.
+The attachment relation is hierarchical and has a clearly defined //active// and //passive// side: The attachment head is the parent node in a tree, but plays the role of the passive partner, to which the child nodes attach. But note, this does not mean we are limited to a single attachment head. Actually, each placement has a list of locating pins and thus can attach to several other placements. For example, a transition attaches to at least two local pipes (clips).
 
 !!!!Relation to memory management
 Attachment on itself does //not// keep an object alive. Rather, it's a direct reference and has to be taken into account when deleting an object. On the other hand, processing nodes in the render engine never depend on placements &mdsash; they always refer directly to the MObject instance or even the underlying asset. In the case of MObject instances, the pointer from within the engine will //share ownership// with the placement (remember: both are derived from {{{boost::shared_ptr}}}).