The first substantial step towards a builder backbone

Defined the structure of the fixture and the outline
of the process leading to creating this data structure.

uml/lumiera/128901

@@ -1,6 +1,6 @@
 format 58
 "Builder" // ProcessingLayer::MObject::Builder
-  revision 20
+  revision 21
   modified_by 5 "hiv"
   // class settings
   //class diagram settings
@@ -74,7 +74,7 @@ format 58
 	iterative
 	activityaction 128773 "define segment"
 	  opaque_action
-	  pin 128133 "inFixture" explicit_type ""
+	  pin 128133 "inContent" explicit_type ""
 	    unordered 
 	    in
 	  end
@@ -107,11 +107,11 @@ format 58
 	end
 
 	flow 130181 "<flow>"
-	  on pin_ref 128133 // inFixture
+	  on pin_ref 128133 // inContent
 	end
 
 	flow 131717 "<flow>"
-	  on pin_ref 128133 // inFixture
+	  on pin_ref 128133 // inContent
 	end
       end
 
@@ -168,6 +168,14 @@ format 58
 
       activitynode 129157 activity_final ""
       end
+
+      activityobject 129157 "Timeline contents"
+	 explicit_type ""
+	unordered 
+	flow 133125 "<flow>"
+	  on pin_ref 128133 // inContent
+	end
+      end
     end
 
     classdiagram 129285 "Builder Tool (Visitor)"

uml/lumiera/129413.diagram

@@ -2,76 +2,72 @@ format 58
 
 activitycanvas 130437 activity_ref 128005 // building the Engine
   show_infonote default drawing_language default show_stereotype_properties default
-  xyzwh 147 27 2000 581 532
+  xyzwh 120 26 2000 468 525
   params
     parametercanvas 130565 parameter_ref 128645 // build Request
-        xyzwh 541 12 2002 113 31
+        xyzwh 401 11 2002 113 31
     end
   end
 end
 activityactioncanvas 130693 activityaction_ref 128645 // activity action configure Tools
   show_infonote default drawing_language default show_stereotype_properties default
   show_opaque_action_definition default
-  xyzwh 529 71 2005 136 41
+  xyzwh 389 63 2005 136 41
 end
 expansionregioncanvas 130821 expansionregion_ref 128133 // establish partitioning
-  xyzwh 359 208 2005 205 96
+  xyzwh 219 200 2005 205 96
   nodes
     expansionnodecanvas 131077 expansionnode_ref 128005 // segment Tool
-        xyzwh 458 203 2007 33 11 label_xy 456 183
+        xyzwh 318 195 2007 33 11 label_xy 316 175
     end
     expansionnodecanvas 132613 expansionnode_ref 128133 // segments
-        xyzwh 460 298 2007 33 11 label_xy 459 312
+        xyzwh 320 290 2007 33 11 label_xy 319 304
     end
   end
 end
 activityactioncanvas 130949 activityaction_ref 128773 // activity action define segment
   show_infonote default drawing_language default show_stereotype_properties default
   show_opaque_action_definition default
-  xyzwh 409 236 2010 135 42
+  xyzwh 269 228 2010 135 42
   pins
-    pincanvas 131205 pin_ref 128133 // inFixture
+    pincanvas 131205 pin_ref 128133 // inContent
-      xyzwh 399 249 2012 11 11 label_xy 315 241
+      xyzwh 259 241 2012 11 11 label_xy 170 250
     end
   end
 end
-activityobjectcanvas 131333 activityobject_ref 128005 // activity object Fixture
-  show_infonote default drawing_language default show_stereotype_properties default
-  xyzwh 177 239 2005 49 31
-end
 activitynodecanvas 133509 activitynode_ref 129029 // fork
-  horizontal xyz 585 147 2005
+  horizontal xyz 445 139 2005
 end
 expansionregioncanvas 133893 expansionregion_ref 128261 // build Processors
-  xyzwh 359 349 2005 272 152
+  xyzwh 219 341 2005 272 152
   nodes
     expansionnodecanvas 134021 expansionnode_ref 128261 // build Tool
-        xyzwh 581 344 2007 33 11 label_xy 573 324
+        xyzwh 441 336 2007 33 11 label_xy 433 316
     end
     expansionnodecanvas 134149 expansionnode_ref 128389 // segments
-        xyzwh 460 344 2007 33 11 label_xy 460 359
+        xyzwh 320 336 2007 33 11 label_xy 320 351
     end
     expansionnodecanvas 136581 expansionnode_ref 128517 // complete Render Engine
-        xyzwh 460 495 2007 33 11 label_xy 496 500
+        xyzwh 320 487 2007 33 11 label_xy 356 492
     end
   end
 end
 activityactioncanvas 134277 activityaction_ref 128901 // activity action create ProcNode
   show_infonote default drawing_language default show_stereotype_properties default
   show_opaque_action_definition default
-  xyzwh 419 389 2010 114 42
+  xyzwh 279 381 2010 114 42
 end
 activityactioncanvas 134405 activityaction_ref 129029 // activity action connect
   show_infonote default drawing_language default show_stereotype_properties default
   show_opaque_action_definition default
-  xyzwh 420 442 2015 113 42
+  xyzwh 280 434 2015 113 42
 end
 activitynodecanvas 134533 activitynode_ref 129157 // activity_final
-  xyz 543 527 2005
+  xyz 403 519 2005
 end
-simplerelationcanvas 131461 simplerelation_ref 128389
+activityobjectcanvas 137093 activityobject_ref 129157 // activity object Timeline contents
-  from ref 131333 z 1999 to point 400 253
+  show_infonote default drawing_language default show_stereotype_properties default
-  line 131589 z 1999 to ref 130437
+  xyzwh 147 157 2005 99 31
 end
 flowcanvas 132101 flow_ref 130309 // <flow>
   
@@ -92,8 +88,8 @@ end
 flowcanvas 133765 flow_ref 130949 // <flow>
   geometry VHV
   
-  from ref 133509 z 2004 to point 595 180
+  from ref 133509 z 2004 to point 455 172
-  line 134789 z 2004 to point 472 180
+  line 134789 z 2004 to point 332 172
   line 134917 z 2004 to ref 131077
   show_infonote default drawing_language default show_stereotype_properties default write_horizontally default
 end
@@ -105,7 +101,7 @@ end
 flowcanvas 135429 flow_ref 131205 // <flow>
   geometry HVr
   
-  from ref 134021 z 2006 to point 595 407
+  from ref 134021 z 2006 to point 455 399
   line 135557 z 2006 to ref 134277
   show_infonote default drawing_language default show_stereotype_properties default write_horizontally default
 end
@@ -119,11 +115,6 @@ flowcanvas 136197 flow_ref 131461 // <flow>
   from ref 134277 z 2009 to ref 134405
   show_infonote default drawing_language default show_stereotype_properties default write_horizontally default
 end
-flowcanvas 136453 flow_ref 131717 // <flow>
-  
-  from ref 131333 z 2004 to ref 131205
-  show_infonote default drawing_language default show_stereotype_properties default write_horizontally default
-end
 flowcanvas 136709 flow_ref 131845 // <flow>
   
   from ref 134405 z 2006 to ref 136581
@@ -131,9 +122,16 @@ flowcanvas 136709 flow_ref 131845 // <flow>
 end
 flowcanvas 136837 flow_ref 131973 // <flow>
   
-  from ref 136581 z 2004 to point 487 524
+  from ref 136581 z 2004 to point 347 516
   line 136965 z 2004 to ref 134533
   show_infonote default drawing_language default show_stereotype_properties default write_horizontally default
 end
-preferred_whz 768 616 1
+flowcanvas 137221 flow_ref 133125 // <flow>
+  geometry VH
+  
+  from ref 137093 z 2004 to point 194 244
+  line 137349 z 2004 to ref 131205
+  show_infonote default drawing_language default show_stereotype_properties default write_horizontally default
+end
+preferred_whz 627 621 1
 end

uml/lumiera/5.session

@@ -1,11 +1,13 @@
-window_sizes 1324 1020 270 1044 872 71
+window_sizes 1615 1020 270 1335 872 71
 diagrams
   classdiagram_ref 136453 // Session backbone
     631 352 100 4 0 0
-  active  objectdiagram_ref 138885 // ModelAssetRelations
+  objectdiagram_ref 138885 // ModelAssetRelations
     730 488 100 4 0 0
   classdiagram_ref 128133 // Session structure
-    835 697 100 4 0 0
+    835 697 100 4 300 0
+  active  activitydiagram_ref 129413 // build flow
+    627 621 100 4 0 0
 end
 show_stereotypes
 selected 
@@ -31,7 +33,7 @@ open
   class_ref 152453 // PlacementRef
   classrelation_ref 178437 // <realization>
   class_ref 153733 // QueryFocusStack
-  classview_ref 128261 // Builder Workings
+  expansionregion_ref 128133 // establish partitioning
   usecaseview_ref 128261 // config examples
   classview_ref 128133 // Engine Workings
   class_ref 164485 // Request

uml/lumiera/lumiera.prj

@@ -1,6 +1,6 @@
 format 58
 "lumiera"
-  revision 64
+  revision 65
   modified_by 5 "hiv"
   cpp_root_dir "../../src/"
 

wiki/renderengine.html

@@ -1077,6 +1077,26 @@ Please note the shortcomings and logical contradictions in the solution currentl
 * The current design rather places the implementation according to the roles of the involved entities, which causes some ping-pong on the implementation level. Especially the ScopeLocator singleton can be accessed multiple times. This is the usual clarity vs. performance tradeoff. Scope resolution is assumed rather to be //not performance critical.//
 </pre>
 </div>
+<div title="BuildFixture" modifier="Ichthyostega" modified="201011290504" created="201011282003" tags="Builder spec operational" changecount="32">
+<pre>//Building the fixture is actually at the core of the [[builder's operation|Builder]]//
+{{red{WIP as of 11/10}}} &amp;rarr; see also the [[planning page|PlanningBuildFixture]]
+
+;Resolving the DAG[&gt;img[Steps towards creating a Segmentation|draw/SegmentationSteps1.png]]
+Because of the possibility of binding a Sequence multiple times, and maybe even nested as virtual clip, the [[high-level model|HighLevelModel]] actually constitutes a DAG, not a tree. This leds to quite some tricky problems, which we try to resolve by //rectifying the DAG into N virtual trees.// (&amp;rarr; BindingScopeProblem)
+
+Relying on this transformation, each Timeline spans a sub-tree virtually separated from all other timelines; the BuildProcess is driven by [[visiting|VisitorUse]] all the //tangible// objects within this subtree. In the example shown to the right, Sequence-β is both bound as VirtualClip into Sequence-α, as well as bound independently as top-level sequence into Timeline-2. Thus it will be visited twice, but the QueryFocus mechanism ensures that each visitation »sees« the proper context.
+
+;Explicit Placements
+Each tangible object placement (relevant for rendering), which is encountered during that visitation, gets //resolved// into an [[explicit placement|ExplicitPlacement]]. If we see [[Placement]] as a positioning within a multi dimensional configuration space, then the resolution into an explicit placement is like the creation of an ''orthogonal base'': Within the explicit placement, each LocatingPin corresponds exactly to one degree of freedom and can be considered independently from all other locating pins. This resolution step removes any fancy dynamic behaviour and all scoping and indirect references. Indeed, an explicit placement is a mere //value object;// it isn't part of the session core (PlacementIndex), isn't typed and can't be referred indirectly.
+
+;Segmentation of Time axis
+This simple and explicit positioning thus allows to arrange all objects as time intervals on a single axis. Any change and especially any overlap is likely to create a different wiring configuration. Thus, for each such configuration change, we fork off a new //segment// and //copy over// all partially touched placements. The resulting seamless sequence of non-overlapping time intervals provides the backbone of the datastructure called [[Fixture]].
+
+;Building the Network
+From this backbone, the actual [[building mechanism|BuilderMechanics]] proceeds as a ongoing visitation and resolution, resulting in the gowth of a network of [[render nodes|ProcNode]] starting out from the source reading nodes and proceeding up through the local pipes, the transitions and the global pipes. When this build process is exhausted, besides the actual network, the result is a //residuum of nodes not connected any further.// Any of these [[exit nodes|ExitNode]] can be associated to a ~Pipe-ID in the high-level model. Within each segment, there should be one exit node per pipe-ID at max. These are the [[model ports|ModelPort]] resulting from the build process, keyed by their corresponding ~Pipe-ID.
+&amp;rarr; see [[Structure of the Fixture|Fixture]]
+</pre>
+</div>
 <div title="BuildProcess" modifier="Ichthyostega" modified="200906071813" created="200706190658" tags="Builder operational img" changecount="30">
 <pre>All decisions on //how // the RenderProcess has to be carried out are concentrated in this rather complicated Builder Subsystem. The benefit of this approach is, besides decoupling of subsystems, to keep the actual performance-intensive video processing code as simple and transparent as possible. The price, in terms of increased complexity &amp;mdash; to pay in the Builder &amp;mdash; can be handled by making the Build Process generic to a large degree. Using a Design By Contract approach we can decompose the various decisions into small decision modules without having to trace the actual workings of the Build Process as a whole.
 
@@ -1708,8 +1728,8 @@ To make the intended use of the classes more clear, consider the following two e
 <pre>a special ProcNode which is used to pull the finished output of one Render Pipeline (Tree or Graph). This term is already used in the Cinelerra2 codebase. I am unsure at the moment if it is a distinct subclass or rahter a specially configured ProcNode (a general design rule tells us to err in favour of the latter if in doubt).
 </pre>
 </div>
-<div title="ExplicitPlacement" modifier="MichaelPloujnikov" modified="200706271458" created="200706220304" tags="def" changecount="2">
+<div title="ExplicitPlacement" modifier="Ichthyostega" modified="201011290457" created="200706220304" tags="def" changecount="3">
-<pre>A special kind (subclass) of [[Placement]]. As such it is always linked to a //Subject//, i.e. a MObject. In addition to the properties of a (unspecific) Placement, the ExplicitPlacement specifies a absolute time and track position for locating the Subject
+<pre>A special kind (subclass) of [[Placement]]. As such it is always linked to a //Subject//, i.e. a MObject. But contrary to the (standard) placements, which may exhibit all kinds of fancy dynamic and scope dependent behaviour, within an explicit placement all properties are resolved and materialised. While the (standard) placement may contain an arbitrary list of LocatingPin objects, the resolution into an explicit placement performs a kind of »orthogonalisation«: each remaining LocatingPin defines exactly one degree of freedom independent of all others. Most notably, the explicit placement always specifies a absolute time and [[output designation|OutputDesignation]] for for locating the Subject.
 </pre>
 </div>
 <div title="Factories" modifier="Ichthyostega" modified="201003160211" created="200708100401" tags="impl discuss excludeMissing rewrite" changecount="24">
@@ -1766,19 +1786,34 @@ Some further details
 * a special case of this factory use is the [[Singleton]] factory, which is used a lot within the Proy-Layer code
 </pre>
 </div>
-<div title="Fixture" modifier="Ichthyostega" modified="201007160052" created="200706220324" tags="def" changecount="10">
+<div title="Fixture" modifier="Ichthyostega" modified="201011290357" created="200706220324" tags="def spec Builder Model" changecount="41">
-<pre>a specially configured sequence list
+<pre>a specially configured view -- joining together high-level and low-level model
 * all MObjects have their position, length and configuration set up ready for rendering.
 * any nested sequences (or other kinds of indirections) have been resolved.
-* every MObject is associated with an ExplicitPlacement, which declares a fixed position (Time, [[Pipe-ID|OutputDesignation]])
+* every MObject is attached by an ExplicitPlacement, which declares a fixed position (Time, [[Pipe|OutputDesignation]])
-* these ~ExplicitPlacements are contained in a ordered List, sometimes denoted as the //effective timeline.//
+* these ~ExplicitPlacements are contained immediately within the Fixture, ordered by time
 * besides, there is a collection of all effective, possibly externally visible [[model ports|ModelPort]]
 
-As the builder and thus render engine //only consults the fixture,// while all editing operations finally propagate to the fixture as well, we get an isolation layer between the high level part of the Proc layer (editing, object manipulation) and the render engine. Creating the Fixture can be seen as a preprocessing step to simplify the build process. For this reason, the process of [[(re)building the fixture|PlanningBuildFixture]] has been designed together with the [[Builder]]
+As the builder and thus render engine //only consults the fixture,// while all editing operations finally propagate to the fixture as well, we get an isolation layer between the high level part of the Proc layer (editing, object manipulation) and the render engine. [[Creating the Fixture|BuildFixture]] is an important sideeffect of running the [[Builder]] when createing the [[render engine network|LowLevelModel]].
 
 !{{red{WIP}}} Structure of the fixture
-The fixture is like a grid, where one dimension is given by the [[model ports|ModelPort]], and the other dimension extends in time. The time axis is grouped in segments of constant structure.
+[&lt;img[Structure of the Fixture|draw/Fixture1.png]]
-A problem yet to be solved is how the fixture relates to the mulitude of top-level timelines, without generating a too fine grained segmentation.
+
+The fixture is like a grid, where one dimension is given by the [[model ports|ModelPort]], and the other dimension extends in time. Within the time dimension there is a grouping into [[segments|Segmentation]] of constant structure.
+
+;Model Ports
+:The model ports share a single uniform and global name space: actually they're keyed by ~Pipe-ID
+:Model ports are derived as a result of the build process, as the //residuum// of all nodes not connected any further
+:Each port belongs to a specific Timeline and is associated with the [[Segmentation]] of that timeline.
+
+;Segmentation
+:The segmentation partitiones the time axis of a single timeline into segments of constant (wiring) configuration
+:Together, the segments form a seamless sequence of time intervals. They contain a copy of each (explicit) placement of a visible object touching that time interval. Besides that, segments are the top level grouping device of the render engine node graph; they are always built and discarded at once.
+:Segments may be //hot swapped// into an ongoing render.
+
+;Exit Nodes
+:Each segment holds an ExitNode for each relevant ModelPort of the corresponding timeline.
+:Thus the exit nodes are keyed by ~Pipe-ID as well (and consequently have a distinct [[stream type|StreamType]]) -- each model port coresponds to {{{&lt;number_of_segments&gt;}}} separate exit nodes, but of course an exit node may be //mute.//
 </pre>
 </div>
 <div title="ForwardIterator" modifier="Ichthyostega" modified="200912190027" created="200910312114" tags="Concepts def spec" changecount="17">
@@ -2784,8 +2819,8 @@ These are used as token for dealing with other objects and have no identity of t
 
 </pre>
 </div>
-<div title="ModelPort" modifier="Ichthyostega" created="201011100234" tags="def" changecount="1">
+<div title="ModelPort" modifier="Ichthyostega" modified="201011290333" created="201011100234" tags="def" changecount="2">
-<pre>Any point where output possibly might be produced. Model port entities are located within the [[Fixture]] &amp;mdash; model port as a concept spans the high-level and low-level view. A model port can be associated both to a pipe in the HighLevelModel and denote a specific ExitNode in the render nodes network.
+<pre>Any point where output possibly might be produced. Model port entities are located within the [[Fixture]] &amp;mdash; model port as a concept spans the high-level and low-level view. A model port can be associated both to a pipe in the HighLevelModel but at the same time denote a set of corresponding [[exit nodes|ExitNode]] within the [[segments|Segmentation]] of the render nodes network.
 
 A model port is rather derived than configured; it emerges when a pipe [[claims|WiringClaim]] an output desitnation and some other entity actually uses this designation as a target, either directly or indirecly. This match of provision and usage is detected during the build process and produces an entry in the fixture's model port table. These model ports in the fixture are keyed by ~Pipe-ID, thus each model port has an associated StreamType.